零后端实战（一）：为什么用飞书多维表格当数据库
内容提要
作者介绍用飞书多维表格作为云端数据库，实现零后端股票记账系统。核心是前端通过代理调用飞书API，避免CORS问题，数据存于飞书，无需服务器和备案。系统包含股票信息、操作记录和设置三个页面，架构用Cloudflare Tunnel和nginx保障安全。系列后续将讲前端搭建、部署和调试。
延伸解读
零后端方案的适用边界
作者选择飞书多维表格作为数据库，主要面向个人或小规模工具类应用，如股票记账。这种方案省去了服务器运维和备案，但并非万能：飞书API有频率和配额限制，不适合高并发或复杂事务场景。若数据量增长或需要复杂查询，可能需迁移至传统数据库。读者应评估自身需求，避免盲目套用。
安全设计的关键点
文章强调浏览器不直连飞书，而是通过代理转发请求，且凭据仅存于内存，不落盘。这种设计降低了密钥泄露风险，但代理本身仍是单点，需确保其安全。Cloudflare Tunnel和nginx仅本机监听，进一步缩小暴露面。读者在类似架构中，应关注代理的权限控制和日志审计，防止敏感信息泄露。
前端聚合派生视图的启示
股票基本信息页不直接读取独立数据表，而是由操作记录前端聚合生成。这种设计减少了数据冗余，但要求前端承担更多计算逻辑。对于复杂报表，可能影响性能。读者可借鉴此思路，在数据源单一的情况下，通过前端计算派生视图，但需权衡实时性和复杂度。
Q&A
为什么选择飞书多维表格作为数据库？
因为飞书多维表格本质是带类型约束的在线表格，字段类型覆盖交易记录需求，提供开放REST API，可视为免运维的云端数据库，无需租服务器、装数据库或写后端CRUD。
浏览器直接调用飞书API会遇到什么问题？如何解决？
浏览器因CORS限制不能直接调用飞书API。解决方案是在前端和飞书之间加一个极薄的代理，开发时用Vite中间件，生产时用常驻Node进程，代理只做转发和换token，不存业务数据。
这个零后端系统的整体架构是怎样的？
浏览器通过HTTPS访问Cloudflare Tunnel，Tunnel将请求转发到本机nginx（仅监听8888），nginx提供静态资源和代理转发，代理（feishu-proxy，仅监听8787）将请求转发到飞书多维表格。本机端口不暴露公网，安全由Cloudflare Tunnel和nginx保障。
系统包含哪三个页面？各自功能是什么？
三个页面：股票基本信息（显示持仓股票数、浮动盈亏、各股持仓卡，由操作记录聚合生成）、股票操作记录（买入/卖出流水，支持筛选、增删改，含未卖出手数）、飞书设置（配置App凭据、多维表格，测试连通性和写权限）。
系统如何保证安全性？
浏览器不直连飞书，凭据通过X-Feishu-Credentials头由代理内存解码后转发，服务器不落盘；nginx和feishu-proxy仅本机监听，公网入口由Cloudflare Tunnel建立，本机端口不暴露公网。
股票基本信息页面是如何获取数据的？
该页面不直接读取飞书独立表，而是完全由操作记录在前端聚合生成的派生视图，用于展示持仓和盈亏。
这个零后端方案适合什么场景？
适合个人或小团队的工具型应用，如股票记账系统，需要快速实现、免运维、免备案，且数据量不大，依赖飞书平台。
