不靠谱的糖饼1. 项目概述与核心价值拆解
1.1 为什么MVP阶段要选择File-Based App
最近在一个内部工具项目里，我把整套架构从“先上数据库”改成了纯文件存储，效果出乎意料地好。这里说的File-Based App，指的不是简单的“读写几个txt文件”，而是以文件系统作为主要数据载体和持久化层的应用形态。配合MVP（Minimum Viable Product，最小可行产品）的开发节奏，这种方案在早期阶段的优势非常明显：不需要搭数据库服务、不需要写SQL迁移脚本、不需要考虑连接池——你只需要想清楚一件事：文件怎么组织，数据怎么落地。
很多团队在MVP阶段犯的最大错误，不是功能没想清楚，而是基础设施上得太重。我见过不少项目，第一周还在画原型，第二周就开始为PostgreSQL选云厂商、设计分库分表方案了。这些动作本身没错，但在产品假设还没验证之前，它们全是沉没成本。File-Based App的思路恰恰相反，它把“数据怎么存”这个问题降维到了最朴素的文件读写层面，让你把有限的精力全部集中在业务逻辑和用户反馈上。
适合参考这篇文章的读者有三类：第一类是在做本地优先（Local-First）应用、原型验证或内部工具开发的工程师；第二类是想快速跑通“想法到可用软件”这条链路的技术创业者；第三类是课程设计、毕业设计或个人作品集项目，需要控制复杂度又想体现工程素养的开发者。
1.2 这个概念解决了什么痛点
传统MVP开发默认走“应用 + 数据库”的双组件模式。双组件意味着双倍的环境问题：数据库要安装、要配账号、要管权限；意味着双倍的部署复杂度：你得考虑数据库实例的运维、备份、版本兼容；还意味着双倍的心智负担：表结构设计要先于业务逻辑，一旦需求变了，改表可能比改代码还痛苦。
File-Based App直接消解了这些问题。文件系统本身就是一个随处可得的数据库，它有目录（相当于表），有文件（相当于记录），有文件内容（相当于字段）。你不需要额外安装任何东西，操作系统天然给你提供了一套持久化方案。对MVP来说，这套方案已经足够可靠：文件可以被创建、读取、更新、删除，支持事务性替换（先写临时文件再改名），支持原子写、支持备份（复制目录就行）、支持权限控制，甚至天然支持版本管理（Git）。
我在实际落地中发现，File-Based方案带来的最大隐形收益是可观测性。数据库里的数据要查还得敲SQL，但文件系统里的数据用文本编辑器直接打开就能看。调试的时候节省了大量脑力——哪个字段不对，打开文件一秒钟就定位了，根本不需要走查询工具。
提示：File-Based App并不是让你永远不要用数据库。它是一种“早期策略”和“特定场景策略”，解决的是MVP阶段“快速验证 + 低成本迭代”的问题。什么时候该迁移到数据库，我会在第3节和第4节详细讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型与架构思路：为什么File-Based在MVP阶段很能打
2.1 文件存储 vs 数据库：一次务实的成本对比
先抛开理论，直接算一笔开发成本账。假设要做一个简单的任务管理应用，用户需要创建任务、标记完成、编辑内容。
如果走数据库方案，你需要：
- 设计表结构（tasks表、users表、标签关联表）
- 写建表语句和索引
- 配置数据库连接与连接池
- 设计ORM模型映射
- 处理数据库迁移（以后字段改了怎么办）
- 考虑并发访问控制
而File-Based方案里，这些工作的总量不变，但形态被简化了：
- 每个任务一个JSON文件，或者所有任务放在一个JSON Lines文件里
- 读取时反序列化，修改后整体写回
- 目录结构天然代表数据归属（比如/users/123/tasks/task_456.json）
从开发工时来看，File-Based至少省掉30%的早期搭建工作。更关键的是，这30%省下来的时间正好是验证产品最需要的黄金时间——你可以更快地把一个能跑的原型丢给真实用户使用。
数据库的另一个隐性成本是“环境一致性”。你的开发机、测试机、演示机、用户的机器，每一台都得保证数据库版本和配置一致。这在MVP阶段经常变成事故现场：明明我本地跑得好好的，到你那里就报连接错误。而File-Based方案只要文件系统存在，就一定能跑。
2.2 常见的File-Based App形态与适用场景
File-Based App不是单一模式，我把它分成四种常见形态，各有用武之地：
形态一：单一大文件存储
所有数据写进一个JSON、CSV或JSONL文件里。适合数据量小（几MB以内）、操作频率不高的场景。优点是实现最简单，整个文件读入内存，处理完写回，逻辑清晰。我做过一个量化策略回测记录工具就是这么干的，全部交易记录存一个CSV，几十MB，每次程序启动加载，实时追加写入，前端查询直接在内存里做。
形态二：多文件目录存储
每个实体一个文件，目录结构表达层级关系。这是最灵活的形态，适合数据之间存在天然归属关系的场景。比如一个博客系统：/posts/目录下每篇文章一个Markdown文件，/comments/目录下每篇文章的评论一个JSON文件。这种形态结合文件命名规则能做很多巧妙设计——用时间戳做文件名天然支持按时间排序，用UUID做文件名避免冲突，用slug做文件名可以直接获得可读的URL。
形态三：混合模式：文件 + 轻量数据库
某些维度用文件，某些维度用SQLite。SQLite本身也是一个单文件数据库，扒开来看依然是一个文件，所以你依然可以用文件备份、文件同步的思路来管理它。这种形态适合数据有一定查询需求但又不复杂的场景。比如待办事项应用，元数据放SQLite方便按多种条件筛选，用户上传的附件直接存文件系统，取各自的优势。
形态四：纯文本语义化存储
用Markdown、YAML这类人类可读格式做“活文档”。这种形态特别适合配置管理、知识库、博客系统。Git天然可以版本化这些文本文件，用户可以不用打开你的应用，直接用编辑器修改数据——这是数据库永远给不了的体验。我的笔记系统就是这种形态，所有笔记是Markdown文件，