零后端实战（一）：为什么用飞书多维表格当数据库
内容提要
作者介绍用飞书多维表格作为云端数据库，实现零后端股票记账系统。核心是前端通过代理转发API请求，避免CORS问题，数据存于飞书，支持持仓聚合和操作记录。文章涵盖架构、安全措施及系列路线，强调免运维、免备案的便捷性。
延伸解读
为什么选择飞书多维表格
作者选择飞书多维表格作为数据库，主要看中其类型约束和开放API，能覆盖交易记录所需字段，且免运维、免备案。相比自建后端，省去了服务器和数据库的维护成本，适合个人小工具。但需注意，这种方案依赖第三方服务，数据安全性和可用性受飞书平台限制，不适合对数据主权要求高的场景。
CORS与代理的权衡
浏览器直连飞书API会遭遇CORS限制，因此作者引入极薄代理，仅做转发和token交换，不存储业务数据。开发时用Vite中间件，生产用Node进程，并通过Cloudflare Tunnel暴露公网，避免端口暴露。这种设计虽增加一层部署，但换来了安全性和灵活性，是零后端方案的关键折中。
前端聚合的派生视图
股票基本信息页不直接读取飞书独立表，而是由操作记录前端聚合生成，体现“数据与视图分离”的思路。这减少了表间关联复杂度，但要求前端承担更多计算逻辑，可能影响大数据量下的性能。读者若采用类似架构，需评估数据规模与前端处理能力的匹配度。
Q&A
为什么选择飞书多维表格作为数据库？
因为飞书多维表格本质是带类型约束的在线表格，提供开放的REST API，可以当作免运维的云端数据库，无需租服务器、装数据库或写后端CRUD，且数据存在飞书，几乎人人都有，还能免备案上线。
如何解决浏览器直接调用飞书API时的CORS问题？
在前端和飞书之间加一个极薄的代理，开发时用Vite中间件，生产时用常驻Node进程，代理只做转发和换token，不存业务数据，也不落盘密钥。
飞书多维表格支持哪些字段类型？
支持日期、单选、多选、数字、文本等类型，这些正好覆盖交易记录需要的字段类型。
整个系统的架构是怎样的？
浏览器通过Cloudflare Tunnel访问公网HTTPS，进入本机nginx（仅监听8888），nginx将静态资源请求转发给前端dist，将/api/feishu/*请求转发给feishu-proxy（仅监听8787），feishu-proxy通过X-Feishu-Credentials头在内存解码凭据后转发给飞书多维表格。本机端口不暴露公网。
系统包含哪些页面？
三个页面：股票基本信息页（显示持仓股票数、浮动盈亏、各股持仓卡，由操作记录前端聚合生成）、股票操作记录页（买入/卖出流水，支持筛选、增删改，含未卖出手数列）、飞书设置页（配置App凭据、多维表格，连通测试与写权限探测）。
股票基本信息页的数据来源是什么？
该页不读飞书任何独立表，完全由操作记录前端聚合出来的派生视图。
本系列文章后续会讲哪些内容？
后续包括：前端工程（深色玻璃拟态UI）、核心读写飞书多维表格（含CORS绕过）、部署上线（免端口免备案）、调试实录（三个真实调试决策）、复盘对比与展望。
作者为什么说“零后端”不是偷懒？
因为“零后端”不是偷懒，而是把“数据库+运维”这件事外包给了飞书，从而免去服务器、数据库和运维的负担。
