File-Based App架构：MVP阶段用文件存储替代数据库的实践指南

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节详细讲。

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文件，You靠目录和文件名组织，既可以用我的应用浏览，也可以直接用Obsidian打开编辑。

做个表简单对比下表格：

2.3 为什么File-Based天然契合MVP方法论

MVP方法论的核心是“用最小成本验证最大不确定性”。这个“最小成本”体现在三个维度：开发时间、基础设施投入、认知负担。

File-Based方案在三个维度全部命中。开发时间上，你不需要写DDL（数据定义语言）、不需要研究ORM的关联映射，直接对着数据模型写CRUD就行。基础设施投入上，零服务依赖，一个进程、一个目录就是全部。认知负担上，团队成员不需要都懂数据库优化和建模，只要理解文件和目录，就能理解和修改数据层。

另外有个很容易被忽视的细节：File-Based方案天然支持“数据随手可改”。QA测出问题，开发直接改一个JSON文件就能模拟各种边界情况；产品经理想调整业务流程，不用等开发排期，自己编辑文件就能看到不同数据下的效果。这种“可篡改性”在早期阶段是巨大的效率红利。

当然，任何技术方案都有自己的边界。File-Based的软肋很明显：不适合高频并发写入、不适合复杂关联查询、不适合海量数据。但在MVP阶段，这些软肋绝大多数根本不会暴露——你还没有那么多用户、那么多数据，也就谈不上性能瓶颈。

3. 文件格式选型与目录设计：MVP数据层的核心细节

3.1 数据格式怎么选：JSON、JSONL、CSV、SQLite还是Markdown

选择文件内部的数据格式，本质上是在“机器的便利性”和“人的便利性”之间做权衡。我的建议是分场景来定。

JSON适合层级结构数据。 比如用户配置、对象快照、复杂嵌套的数据。JSON的问题是大文件性能差——你不能只读其中一小段，要整个文件加载到内存再解析。所以别把JSON用在大规模数据上，几百KB没问题，几十MB就有点难受了。

JSONL是JSON的升级版， 每一行一个独立JSON对象。它继承了JSON的可读性，但解决了两个关键问题：可以逐行流式读取，不用全量加载；追加方便，直接在文件末尾append一行就是插入操作。这在日志类、事件类数据场景特别好用。我做的事件埋点采集工具用的就是JSONL，每天几十万条事件，单文件几十MB，读取时一行行解析，内存占用极低。

CSV是表格数据的经典选择。 它最大的好处是通用——Excel、Numbers、Python pandas都能直接打开处理。适合数据分析师需要频繁导出导入的场景，或者数据本来就是二维表结构的。但CSV有几个坑：转义规则不够标准，字段里包含逗号、换行符时容易错乱；没有嵌套结构，不适合复杂数据类型；字符编码容易出问题（建议统一用UTF-8 with BOM，至少用Excel打开时不会乱码）。

SQLite看着像数据库，本质上还是一个文件。 它的优势是支持SQL查询、事务、索引，性能比纯文件读写好得多。对MVP来说，SQLite是“退一步的File-Based”，适合那些你预估很快会有复杂查询需求的项目。缺点是文件不能直接用文本编辑器改了，调试的时候少了一个便利性。

Markdown/YAML适合内容和配置型数据。 如果你做的是博客、笔记、文档类应用，Markdown作为存储格式是最妥的：Git友好、人类可读、生态成熟（各种解析器、渲染器都有）。YAML更适合配置类数据，层级清晰，注释友好，很多静态站点都用它做配置。

我的经验是：MVP阶段别在一棵树上吊死。可以用JSONL做主体数据存储，用JSON做配置和索引，用Markdown做用户可见内容，只要能说清每一种格式的边界，混用完全没问题。

3.2 目录结构设计：好的命名是半个架构

File-Based方案里，目录和文件命名不只是“为了好看”，它们本身就是数据模型的一部分。好的目录设计能让你写极少的查询代码，甚至不需要索引。

先看一个反面案例：把所有数据平铺在一个目录下，文件名用递增数字（1.json、2.json、3.json）。这种设计没有任何结构信息，要找某个用户的数据必须遍历所有文件——相当于数据库全表扫描。

正面案例应当是这样的结构：

code复制data/
  users/
    user_123abc/
      profile.json
      tasks/
        task_1699999999_abcd.json
        task_1700000001_efgh.json
  global/
    config.json
    seq_counter.json

这个结构里三个设计要点：

用目录表达归属关系。user_123abc目录下放这个用户的所有数据，那么在程序里查找用户的tasks，只需要拼路径data/users/user_123abc/tasks/，然后列目录就行。这比写SELECT * FROM tasks WHERE user_id = '123abc'还要直观。

用文件名嵌入元数据。task文件名的前缀是时间戳（1699999999），后缀是简短ID。排序直接用文件名字符串排序就是按时间排序，不需要额外的时间字段。ID后缀后面两位避免同一秒创建多个任务的冲突。

隔离用户数据目录。这带来的隐藏收益是：备份用户可以只复制其目录；删除用户直接删目录；迁移用户可以打包目录下发。

还有一个容易被忽略的关键点：索引与目录的拆分。目录足够用来做“按归属查找”，但不适合做“全量搜索”。所以我会在data/index/下维护几个索引文件，比如tags_to_task_ids.json，它是一个Map，key是标签，value是任务ID列表。这样要按标签筛选时，先读索引拿ID列表，再按ID逐个读任务文件，效率不差。

提示：索引文件会面临一致性问题。我的做法是把索引重建做成一个幂等操作，应用启动时自动比对目录下的实际文件与索引的差异并修复。这个保险机制让我几乎从没有被索引不一致坑过。

3.3 原子写入与数据一致性：File-Based的“事务”怎么做

File-Based没有数据库的事务机制，但这不代表你无法保证数据安全。核心技巧就是原子写入三部曲：

第一步，写入临时文件。修改数据时，先将新内容写入同目录下的临时文件，比如task_1700000001.tmp。

第二步，执行文件替换。写入成功并flush到磁盘后，用rename操作（Go里是os.Rename，Python里是os.replace，Node里是fs.renameSync）把临时文件替换正式文件。文件系统保证rename操作是原子的——要么旧文件还在，要么新文件已就位，不存在中间状态。

第三步，删除旧文件。rename本身会覆盖旧文件，不需要额外清理。

这套方案保证了单文件写入的原子性。但如果一次操作涉及多个文件（比如更新任务的同时要更新索引），那就需要“两阶段提交”的思路：先把所有新内容写入临时文件，再逐个rename替换；一旦中途失败，启动时通过索引重建机制恢复一致性。

另外一个细节：写入时把临时文件放在同一个目录而不是/tmp目录。原因是rename操作要求源文件和目标文件在同一个文件系统分区上，跨分区会失败。放在同目录写临时文件不会有这个问题。

4. 实操过程与核心环节实现：手把手做一个笔记类MVP

4.1 需求定义与MVP边界划定

说再多理论不如直接演示一遍。我用一个“极简笔记应用”的案例，完整走一遍File-Based MVP的开发流程。目标读者是你——无论你是技术栈是Python、Node还是Go，核心思路都能照搬。

产品假设：有一类用户，他们需要快速记笔记，并且希望笔记是纯文本Markdown，能被其他编辑器共用。核心功能三个：

• 创建与编辑笔记（Markdown格式）
• 按标签查找笔记
• 跨设备备份（这一步通过同步目录实现）

MVP阶段明确砍掉：多人协作、富文本编辑、移动端适配、账号体系。砍掉这些是有意为之——它们没有触碰核心假设“Markdown文件是爽的”，都属于后续验证的市场功能。

4.2 项目结构与数据层代码实现

我用的技术栈是Node.js加Express，无任何数据库依赖。目录结构如下：

code复制notes-app/
  src/
    server.js          # HTTP服务入口
    storage.js         # 数据层：文件的增删改查
    index.js           # 索引管理器
  data/
    notes/
    tags.json
    meta/
      seq_counter.json
  public/
    index.html          # 极简前端页面
  package.json

数据层最关键的是storage模块。核心方法如下：

javascript复制// src/storage.js
const fs = require('fs/promises');
const path = require('path');

const DATA_ROOT = path.join(__dirname, '..', 'data');
const NOTES_DIR = path.join(DATA_ROOT, 'notes');

async function saveNote(note) {
  // note: { id, title, content, tags, updatedAt }
  const fileName = `${note.updatedAt}_${note.id}.md`;
  const filePath = path.join(NOTES_DIR, fileName);
  const tempPath = filePath + '.tmp';
  
  // 内容使用YAML front matter + Markdown正文
  const fileContent = [
    '---',
    `title: ${note.title}`,
    `tags: ${note.tags.join(',')}`,
    `id: ${note.id}`,
    `updatedAt: ${note.updatedAt}`,
    '---',
    '',
    note.content,
    ''
  ].join('\n');
  
  // 原子写入：先写临时文件，再rename
  await fs.writeFile(tempPath, fileContent, 'utf8');
  await fs.rename(tempPath, filePath);
}

async function deleteNote(id) {
  const note = await findNote(id);
  if (!note) return;
  const filePath = path.join(NOTES_DIR, `${note.updatedAt}_${note.id}.md`);
  await fs.unlink(filePath);
}

async function findNote(id) {
  const files = await fs.readdir(NOTES_DIR);
  for (const file of files) {
    if (file.includes(`_${id}.md`)) {
      return parseNoteFile(path.join(NOTES_DIR, file));
    }
  }
  return null;
}

这里的核心设计是：文件名即索引。一条笔记的最近更新时间在文件名里，按文件名排序就是按时间倒序排序。程序里不用维护一个“最近更新列表”——直接列目录、按文件名排序就出来了。

4.3 索引与搜索实现

全目录扫描在笔记量小的时候没毛病，但为了演示“文件索引是怎么玩的”，我加上标签索引。tags.json的数据结构如下：

json复制{
  "工作": ["note_1699999999_ab12", "note_1700000001_cd34"],
  "学习": ["note_1700000001_cd34", "note_1700000002_ef56"]
}

索引更新逻辑在每次创建、更新、删除笔记时调用。为了保险，我加上启动时的重建逻辑：

javascript复制// src/index.js
async function rebuildIndex() {
  const files = await fs.readdir(NOTES_DIR);
  const tags = {};
  for (const file of files) {
    if (!file.endsWith('.md')) continue;
    const note = await parseNoteFile(path.join(NOTES_DIR, file));
    note.tags.forEach(tag => {
      if (!tags[tag]) tags[tag] = [];
      tags[tag].push(note.id);
    });
  }
  await atomicWriteJSON(path.join(DATA_ROOT, 'tags.json'), tags);
}

虽然rebuildIndex要遍历所有文件，但因为它只在启动时运行一次，对体验的影响可以忽略。而运行时的索引更新是局部操作，只动对应标签的数组，成本很低。这种“全量重建 + 增量更新”的双保险策略让我不用过度担心索引一致性。

4.4 跨平台与同步的考虑

File-Based方案在同步方面有天然优势：笔记全是Markdown文件，可以直接放到Dropbox、iCloud Drive、Syncthing任意一个同步目录里，跨设备自动同步。我在这个MVP里把data目录暴露成可配置项，用户完全可以把data指向自己的网盘同步目录。

但这里有个教训：同步状态下要格外小心文件锁冲突。两台设备同时修改同一个笔记文件，同步工具可能会产生冲突副本（比如“filename (conflicted copy)”）。我的应对策略有两个层面：一是文件名上带上写入时间戳，减少“同一文件被双方同时修改”的概率；二是在读取时忽略带“conflicted”字样的文件，并把冲突文件单独列到日志里提醒用户处理。

4.5 数据备份与恢复

备份一个File-Based App比备份数据库简单太多——直接复制data目录即可。我在项目里写了一个压缩备份脚本，每天自动跑一次：

bash复制tar -czf backups/notes_$(date +%Y%m%d).tar.gz data/

恢复同样简单，把备份解压覆盖data目录，重启服务就完成了。这里有个细节：恢复时需要先删除现有索引文件，否则启动时rebuildIndex可能会把旧索引当新的合并进去。更稳妥的做法是恢复后先清空data/index目录再启动。

提示：File-Based最适合的风格是“把数据当源代码管理”。给data目录初始化一个Git仓库，每次修改自动commit，这样就有了完整的历史版本。回滚任何数据错误都只需要git checkout——这体验比数据库的时间点恢复还舒服。我在笔记项目里加了自动commit的钩子，误删除恢复的成本几乎为零。

5. 常见问题与优化方向：File-Based App的避坑实录

5.1 性能问题：目录扫描太慢怎么办

第一个真实踩过的坑是：文件数量多了以后，列目录操作会明显变慢。我用Python做过一个爬虫调度系统，每个任务一个JSON文件，跑了半年后积累了几万个文件。Windows上列目录要好几秒，程序启动变得很卡。

解决思路有三层。第一层是分层目录，不要把所有文件放一个目录里，按月份或按ID哈希拆分子目录。例如data/2024/11/这样，每次读取只需要扫描一个子目录，扫描量缩小一个数量级。

第二层是引入索引缓存。启动时扫描一次全部文件，后续读取直接走内存索引，只有写操作时才落到文件系统。这本质上把文件目录变成了“可持久化的内存数据结构”，文件只是底层持久化载体而已。

第三层是设计时控制文件总量。如果单个文件很小（几KB），那几万个文件就有点多了。考虑合并文件——比如把一天内的日志合并成一个JSONL文件，而不是每次事件一个文件。我常用的经验值是：单个目录文件数控制在2000以内，单文件大小控制在1MB以内，这个范围内纯文件方案体验极佳。

5.2 并发写入：多进程/多线程同时写同一个文件

File-Based的单文件并发写入是个大坑。两个进程同时打开同一个文件写入，最后写的内容取决于系统调度顺序，可能出现互相覆盖。

最直接的解法是进程内加锁 + 进程间用文件锁。Node.js里有proper-lockfile这个库，Python有fcntl（Unix）或msvcrt（Windows）。文件锁的做法是：创建一个带有特殊标志的锁文件（比如notes.lock），写入前尝试获取锁，拿到锁才允许写入，写完释放锁。

另一个解法更简单粗暴：每个进程写自己独立的数据目录，最后通过合并机制汇总。这在分布式场景下适用，但对MVP过度设计了，知道思路即可。

如果用的是SQLite形态，它的底层本身就处理了并发，直接用事务就好。所以当你发现并发访问难以用文件锁解决时，就该认真考虑是不是该切到SQLite了。

5.3 数据损坏与恢复策略

文件存储的数据损坏主要来源三方面：非正常退出导致写入不完整、同步工具冲突产生坏文件、人为误编辑。

非正常退出的解决方案就是我前面讲的原子写入——临时文件加rename。只要这个动作做对了，进程崩溃最多丢最后一次未完成写入，已经写入的数据是完整的。

同步工具冲突的解法是读取时做文件内容校验。每个笔记文件头部我写了一段front matter，其中包含一个version字段。读取时校验front matter格式是否完整，如果解析失败就把文件隔离到corrupted/目录，防止坏数据流向API层。

人为误编辑就要靠前面说的Git方案了。我把Git整合进了MVP——每次数据变更自动commit，历史版本全保留。有一次我把一个重要的配置文件改坏了好几天没发现，等发现时靠Git回滚到一周前的版本，一点损失没有。这个体验让我坚定了Git做数据层的可靠性兜底。

5.4 从File-Based迁移到数据库的正确时机

File-Based方案是优秀的MVP策略，但产品做起来以后，有些信号出现时说明该迁数据库了：

信号一：查询维度越来越多。文件目录结构本质上只能支撑一两个查找维度（按目录、按文件名）。当你想按内容全文搜索、按多个标签组合筛选、按任意时间范围聚合统计时，文件系统的效率会急剧下降。

信号二：并发写冲突变频繁。多个用户同时修改数据，文件锁机制会变成性能瓶颈，等待锁的时间超过数据处理时间。

信号三：数据量级突破单机阈值。文件方案受限于单机磁盘和内存。当数据量超过几十GB，或者需要横向扩展时，数据库是必然归宿。

信号四：需要复杂事务与一致性保障。涉及金钱交易、库存扣减这类绝不能出错的场景，直接用数据库事务要比文件方案可靠得多。

但在决定迁移时，File-Based架构为你留了一条后路：因为数据天然是独立文件，你可以写一个迁移脚本逐个文件解析后批量插入数据库，整个过程可以在线执行，不需要停机，不需要复杂的双写逻辑。这就是我为什么一直强调“文件是数据最自然的表现形式”的原因。

5.5 监控与可观测性：文件版本可以当审计日志用

数据库方案要做审计功能得专门建表、写触发器，而File-Based方案里这个功能是白送的。因为每次改动必然生成一个新版本的文件内容，Git记录天然就是完整的审计日志。谁在什么时候改了哪个文件、改了什么内容，全部有迹可循。

我做了个小工具，定时扫描data目录，把变更记录导出成JSON报告，后端管理页面直接展示“最近7天数据变化明细”。这个功能在MVP阶段用来追踪用户bug非常有用——用户报告说“我的数据丢了”，我打开Git历史一看，原来是他自己误删了，定位问题时间从小时级降到分钟级。

6. 扩展方向：File-Based MVP还能怎么玩

6.1 作为离线优先应用的存储核心

离线优先（Offline First）是File-Based方案的主场。移动端和桌面端应用天然受限于网络条件，离线时数据必须能暂存本地。File-Based方案让“停止联网、照样使用”成为标配能力——数据写本地文件，联网后由同步模块把改动推送到服务器。

我做过一个店务管理工具的MVP，收银员在信号不好的地下商铺里也能正常记单，因为单据全部先落地为本地JSON文件，等到有网络时后台线程再上传。这个体验如果是纯云架构，光处理断网重连的数据一致性就够写几十个Issue了。

6.2 与静态站点生成器结合做内容中台

File-Based的结构与静态站点生成器（如Hugo、VuePress）天然契合。你可以在自己的App里管理内容，数据落地为Markdown文件，然后直接用静态站点生成器渲染成网站。这样内容管理后台与前端站点解耦，但共享同一套文件数据——不需要API，不需要同步任务。

举个例子，我做过一个团队Wiki MVP：同事们在Web界面里编辑页面，保存时写Markdown文件到content/目录，前端触发Hugo重新构建，一分钟内新的Wiki页面就上线了。整个过程没有数据库，没有CMS，就靠着文件系统的中转，复杂度极低。

6.3 数据导入导出的天然优势：可移植性

File-Based方案在数据可移植性上的优势简直是降维打击。用户随时可以把数据导出成一个zip包，里面是结构清晰的目录和文件。对用户体验来说，“我的数据随时可以带走”是一种巨大的信任感。这也符合“数据所有权”的趋势——用户不想把数据锁死在某个服务商的数据库里。

我在笔记MVP里直接加了一个“导出全量备份”按钮，后台就是把data目录打包。用户拿到的是一个文件夹而不是专有格式文件，直观、可信。

7. 最后分享两个实操心得

写到这里，把我在File-Based App开发中最想强调的两条经验分享出来。

第一条经验是：文件的组织方式，就是你系统的架构方式。很多人觉得目录结构不重要，随便放一下，后面靠代码来兜底。但事实是，目录结构一旦定义好，你的代码逻辑就清晰了大半。好的目录设计是“代码都没写，架构已经完成了”。花时间把目录结构想清楚，比花时间选框架和ORM要值得多。

第二条经验是：File-Based方案的价值不在于“不用数据库”这个表面，而在于它逼你把数据模型想简单。数据库太强大了，强大到你会下意识设计复杂的数据关系。而文件存储的能力边界很明确，这个边界会反过来倒逼你精简功能、聚焦核心——这恰恰是MVP最需要的思维方式。在人力和时间都最有限的早期阶段，“没得选”有时候比“什么都选”更高效。

这两条经验，是我在多个项目实践中反复验证过的。如果你正在做一个MVP，不妨试试用File-Based的方式把数据层搭起来——你可能会跟我一样，发现原来“做简单的事情”比“做看起来正确的事情”更有价值。