零后端实战（一）：为什么用飞书多维表格当数据库
内容提要
本文介绍“零后端”方案，用飞书多维表格作为云端数据库，通过前端加代理实现股票仓位管理。架构包括浏览器、Cloudflare Tunnel、nginx和飞书API代理，避免CORS问题且不落盘密钥。系统含三个页面：股票信息、操作记录和飞书设置，数据由前端聚合派生。系列后续将讲前端搭建、部署和调试。
延伸解读
零后端方案的适用边界
本文的“零后端”并非完全无后端，而是将数据库和运维外包给飞书多维表格，同时保留一个极薄的代理用于转发和换token。这种方案适合个人工具或小规模应用，如股票仓位管理，数据量不大且并发低。若业务增长或需要复杂事务，飞书API的速率限制和功能边界可能成为瓶颈，需评估是否仍适用。
安全设计的关键点
安全上，浏览器不直连飞书，避免CORS问题；凭据通过X-Feishu-Credentials头由代理内存解码后转发，服务器不落盘密钥。公网入口由Cloudflare Tunnel建立，本机端口不暴露，nginx和代理仅监听本机。这种设计减少了密钥泄露风险，但需注意代理进程的内存安全，以及Cloudflare Tunnel的配置正确性。
派生视图的架构启示
股票基本信息页不读独立表，而是由操作记录前端聚合派生，这减少了数据冗余和一致性维护。类似地，在零后端架构中，应尽量让前端承担计算和派生逻辑，以降低对后端API的依赖。但需注意前端性能，当数据量大时，聚合计算可能变慢，需考虑分页或缓存策略。
Q&A
为什么用飞书多维表格当数据库？
飞书多维表格本质是带类型约束的在线表格，支持日期、单选、多选、数字、文本等字段，正好覆盖交易记录所需字段类型，并提供开放的REST API，相当于免运维的云端数据库，无需租服务器和写后端CRUD。
零后端方案的整体架构是怎样的？
浏览器通过HTTPS访问Cloudflare Tunnel，Tunnel将请求转发到本机nginx（仅监听8888），nginx将静态资源请求指向dist前端，将/api/feishu/*请求转发给feishu-proxy代理（仅监听8787），代理将请求转发到飞书多维表格API。
如何解决浏览器直接调用飞书API的CORS问题？
在浏览器和飞书之间增加一个极薄的代理（开发时用Vite中间件，生产时用常驻Node进程），代理只做转发和换token，不存业务数据，也不落盘密钥。浏览器请求先到代理，由代理转发给飞书API，从而绕过CORS限制。
系统包含哪三个页面？分别有什么功能？
三个页面：1. 股票基本信息页：显示持仓股票数、浮动盈亏、各股持仓卡（持仓中/已清仓），由操作记录前端聚合派生；2. 股票操作记录页：管理买入/卖出流水，支持筛选、新增/编辑/删除，含“未卖出手数”列（FIFO口径）；3. 飞书设置页：配置App凭据、多维表格，进行连通测试与写权限探测。
为什么浏览器不能直接访问飞书API？
因为浏览器有CORS（跨域资源共享）限制，直接调用飞书API会被拦截，所以需要通过代理转发请求。
系统如何保证密钥安全？
凭据通过X-Feishu-Credentials头由代理在内存中解码后转发，服务器不落盘密钥。同时，nginx和feishu-proxy仅监听本机端口，不暴露给公网，公网入口由Cloudflare Tunnel建立，进一步保障安全。
股票基本信息页的数据来源是什么？
股票基本信息页不读飞书任何独立表，完全由操作记录前端聚合出来的派生视图，即根据操作记录实时计算当前持仓和浮动盈亏。
零后端方案适合什么场景？
适合个人或小团队的工具类应用，如本文中的股票仓位管理，需要数据库但不想运维服务器和数据库，希望快速上线且免备案的场景。
