零后端实战（一）：为什么用飞书多维表格当数据库
内容提要
作者介绍用飞书多维表格作为云端数据库，实现零后端股票记账系统。核心是前端通过代理调用飞书API，避免CORS问题，数据存于飞书，无需服务器和备案。系统包含股票信息、操作记录和设置三个页面，架构安全，凭据不落盘。系列文章将涵盖前端搭建、API读写、部署和调试。
延伸解读
零后端方案的适用边界
本文的“零后端”并非完全无服务器，而是将数据库和运维外包给飞书，同时仍需一个极薄的代理转发请求。该方案适合个人工具、低频读写场景，如股票记账。若涉及高并发、复杂事务或敏感数据，飞书多维表格的API限制和第三方依赖可能成为瓶颈，需谨慎评估。
安全设计的关键点
作者强调凭据不落盘，通过代理内存解码转发，且本机端口不直接暴露公网，由Cloudflare Tunnel提供HTTPS入口。这种设计降低了密钥泄露风险，但代理本身仍是信任核心。读者若复刻，需确保代理进程安全，并定期轮换凭据，避免因代理被攻破导致数据泄露。
前端聚合派生视图的启示
股票基本信息页不直接读取独立表，而是由操作记录前端聚合生成，这减少了表间同步需求，也体现了多维表格作为数据源的灵活性。但派生视图依赖前端计算，若数据量大或逻辑复杂，可能影响性能。读者可借鉴此思路，将简单统计放在前端，复杂查询则需考虑后端处理。
Q&A
为什么选择飞书多维表格作为数据库？
因为飞书多维表格本质是带类型约束的在线表格，提供开放的REST API，可以当作免运维的云端数据库，无需租服务器、装数据库或写后端CRUD，且数据存在飞书，几乎人人都有，还能免备案上线。
如何解决浏览器直接调用飞书API时的CORS问题？
在前端和飞书之间加一个极薄的代理，开发时用Vite中间件，生产时用常驻Node进程，代理只做转发和换token，不存业务数据，也不落盘密钥。
这个零后端系统的整体架构是怎样的？
浏览器通过HTTPS访问Cloudflare Tunnel，Tunnel将请求转发到本机nginx（仅监听8888），nginx将静态资源请求指向dist前端，将/api/feishu/*请求转发给feishu-proxy（仅监听8787），feishu-proxy再通过X-Feishu-Credentials头携带凭据，内存解码后转发到飞书多维表格。本机端口不暴露公网。
系统包含哪三个页面？分别有什么功能？
1. 股票基本信息：显示持仓股票数、浮动盈亏、各股持仓卡（持仓中/已清仓），由操作记录前端聚合派生。2. 股票操作记录：管理买入/卖出流水，支持筛选、新增/编辑/删除，含未卖出手数（FIFO口径）。3. 飞书设置：配置App凭据、多维表格，进行连通测试和写权限探测。
系统如何保证安全性，特别是凭据不落盘？
浏览器不直连飞书，凭据通过X-Feishu-Credentials头由代理在内存中解码后转发，服务器不落盘密钥。nginx和feishu-proxy仅监听本机，公网入口由Cloudflare Tunnel建立，本机端口不暴露公网。
这个系列文章后续会讲哪些内容？
后续包括前端工程（深色玻璃拟态UI搭建）、核心的飞书多维表格读写（含CORS绕过）、部署上线（免端口免备案）、调试实录（三个真实调试决策）以及复盘对比与展望。
