用文件存储实现MVP：零数据库记账App开发全复盘

上个月我给自己定了个挑战：两周内做出一款真正能跑通的记账类App MVP，用来验证"极简记账+月度复盘"这个需求到底有没有人买账。当时的硬性约束有三条：不搭服务器、不配数据库、不搞账号体系，所有数据全部落在本地文件里。最终项目第12天交付内测版，存储层全程用的是File-Based方案，一行数据库代码都没写。这篇文章把整个项目的构思、选型、实现步骤和踩坑记录完整复盘一遍，写给正在做MVP验证、或者对轻量级本地存储方案感兴趣的朋友。

先说结论：File-Based存储做MVP，核心价值不是"简单"，而是"把验证成本压到最低"。数据量在几千条以内时，文件读写的性能完全够用，调试时直接打开文件就能看到数据长什么样，比查数据库爽太多。

1. 项目构思与方案定位

1.1 为什么选File-Based存储，而不是直接上数据库

很多人一听说要做App，第一反应就是"上SQLite"或者"接个云端数据库"。但在MVP阶段，这个选择往往是被惯性带着走的，而不是被需求推着走的。我这次特意压住这个冲动，用文件存储，背后有三个原因。

第一，MVP的核心目标是验证需求，不是验证架构。记账App的核心操作是"记一笔"和"看汇总"，数据模型极其简单，就是一张流水表加一张分类表。这种量级下的增删改查，JSON文件完全扛得住。等到真的需要复杂查询、多端同步、万人并发的时候再换数据库，那时候需求已经被验证过了，换架构的成本是值得的。

第二，调试效率高得离谱。用数据库时，你要么连Android Studio的Database Inspector，要么装第三方工具，要么写SQL去查。用文件方案呢？直接把应用私有目录下的JSON文件拖出来，找个编辑器打开就能看。出问题了，人肉读文件比查日志都快。

第三，部署和分发成本为零。不需要在用户设备上初始化数据库、不需要处理版本迁移、不需要考虑服务器端存储。对MVP来说，这些省下来的时间全部可以投入到核心功能上。

1.2 MVP的边界到底怎么划

做MVP最常见的问题就是边界失控，功能越加越多，最后两周变成两个月。这次我给自己划了几条硬边界，现在看非常有效。

功能边界上，只做四件事：添加一笔账目、展示账目列表、按分类筛选、查看当月总支出。其余什么图表分析、预算管理、多账户、照片凭证、语音记账，全部砍掉。有些功能不是不好，而是第一版不该做。

用户边界上，不登录、不注册、不同步，默认单机单用户。好友分享、账单同步这些听起来很酷，但会让存储层复杂度直接翻几倍。File-Based方案最怕的就是多端并发写同一个文件，MVP阶段完全没必要给自己挖这个坑。

数据边界上，只保留最核心的字段：金额、分类、备注、时间。不做收支类型的双轨制，用正负数表示收入支出。这个决定让整个数据模型减少了一半的字段，文件读写和界面渲染都简单了很多。

1.3 技术栈选型思路

存储方案定了File-Based之后，上面的技术框架我选的是Flutter 3.x。理由很简单：我自己熟悉，而且Dart语言的dart:io结合path_provider插件，操作本地文件的API很直接，不需要额外引入重量级依赖。

如果你做的是原生Android项目，直接用java.io.File或者Kotlin的kotlin.io也能达到同样的效果；做iOS原生就用FileManager。关键是原理相通，都是把数据序列化成字符串，写到应用沙盒的私有目录里。我这里以Flutter为例展开，因为它的跨平台特性可以让这套存储层代码同时跑在Android和iOS上，正好符合MVP"快速验证"的定位。

2. 文件存储方案设计要点

2.1 数据模型与文件格式的选择

File-Based方案里，最核心的决定就是"用什么格式落盘"。我对比过三种主流格式，最终选了JSON。

CSV的好处是体积最小、可以用Excel直接打开编辑，但缺点是嵌套结构表达起来非常痛苦，比如一条账目如果对应多个标签，CSV处理起来就是灾难。Markdown/纯文本适合给人阅读的场景，但程序解析和写入的容错性差，一个格式错了整行数据就读不出来。JSON是JavaScript Object Notation的缩写，虽然带个"JavaScript"，但现在已经成了跨语言通用的数据交换格式，Dart、Kotlin、Swift对它的支持都非常完整，标准的jsonEncode和jsonDecode就能搞定，不需要额外引库。

我的数据模型设计成两个文件分开放：records.json存账目流水，settings.json存用户偏好（比如默认货币单位、默认分类）。这两个文件对应的Dart模型类大致是：

dart复制class Record {
  final String id;
  final double amount;
  final String category;
  final String note;
  final DateTime createdAt;

  Record({
    required this.id,
    required this.amount,
    required this.category,
    required this.note,
    required this.createdAt,
  });

  Map<String, dynamic> toJson() => {
        'id': id,
        'amount': amount,
        'category': category,
        'note': note,
        'createdAt': createdAt.toIso8601String(),
      };

  factory Record.fromJson(Map<String, dynamic> json) => Record(
        id: json['id'] as String,
        amount: (json['amount'] as num).toDouble(),
        category: json['category'] as String,
        note: json['note'] as String? ?? '',
        createdAt: DateTime.parse(json['createdAt'] as String),
      );
}

注意两个细节：ID我用的是时间戳加随机数生成的长字符串，避免在本地文件里维护自增序列，省掉一整套状态管理；时间字段用ISO 8601格式的字符串存储，而不是毫秒时间戳，因为前者一眼能看懂，排查问题的时候直接打开文件就能确认时间对不对，效率高很多。

2.2 文件目录与命名规范

Flutter的path_provider插件提供了两个常用目录：getApplicationDocumentsDirectory()和getTemporaryDirectory()。两者的核心区别在于前者是持久化目录，App卸载前系统不会清理，适合存放用户数据；后者是临时目录，系统可能在任意时刻清空，适合存放缓存和临时文件。

我的方案是：records.json和settings.json放在Documents目录下，应用启动时如果发现文件不存在，就初始化一个空的数据结构并落盘。这样目录结构非常清晰：

code复制<Documents目录>/
├── records.json
└── settings.json

命名规范方面，我坚持用全小写加下划线，不用空格和中文。虽然File-Based方案允许任何文件名，但在后续做备份、导出、迁移的时候，一个干净的文件名能避免很多奇奇怪怪的编码问题。

2.3 读写策略与性能边界

File-Based方案不是没有性能死角。我实测下来，在普通中端Android设备上，每次writeAsString写入一个几百KB的JSON文件，耗时大概在20到50毫秒之间。这个数字用来承载MVP场景完全没问题，但如果有人天真的以为文件存储可以无限扩容，那就错了。

我的建议是给File-Based存储画一条清晰的能力边界：单文件大小控制在1MB以内，数据条数控制在1万条以内。超过这个量级，要么引入SQLite做数据库索引，要么做文件分片（比如按月拆分文件）。我在MVP里就预留了按月拆分的可能性：文件名设计成records_202401.json这样的格式，只是第一版先不实现，写死在records.json，等数据量上来再切换。

另外一个非常重要的策略是原子写。什么叫原子写？就是不要让"写入"这个操作只体现在把旧文件覆盖成新文件上。正确做法是：先写一个临时文件（比如records.json.tmp），写完并确认没问题之后，再把临时文件重命名为正式文件。这样即使写入过程中App被系统杀掉，旧数据文件依然是完整的，不会出现"写一半、文件损坏"的悲剧。这个细节成本极低，但价值极高，强烈建议所有做File-Based存储的人遵守。

3. 核心功能实现步骤

3.1 项目骨架搭建与依赖配置

创建Flutter项目的命令很简单，这里不赘述，重点说一下依赖。一个最小可用的File-Based MVP只需要两个额外包：path_provider用于获取文件目录，intl用于日期格式化。前者是文件方案的基石，后者是让界面显示"2024年1月15日 12:30"而不是"2024-01-15T12:30:00.000Z"的关键。

在pubspec.yaml中配置依赖后，我建立一个名为core/storage/的目录，专门放存储层代码。这里的原则是"存储与UI完全解耦"，UI层的任何widget都不直接操作File对象，而是通过一个RecordRepository接口来读写数据。这样后续如果要从文件存储切换到数据库，只需要替换RecordRepository的实现类，UI层一行都不用改。

3.2 文件持久化层实现

核心存储类我命名为FileRecordStore，主要职责是封装JSON文件的读写。关键代码骨架如下：

dart复制class FileRecordStore {
  final Directory _docDir;
  static const String fileName = 'records.json';

  FileRecordStore(this._docDir);

  File get _file => File('${_docDir.path}/$fileName');

  Future<List<Record>> loadRecords() async {
    try {
      if (!await _file.exists()) return [];
      final jsonStr = await _file.readAsString();
      final list = jsonDecode(jsonStr) as List<dynamic>;
      return list.map((e) => Record.fromJson(e as Map<String, dynamic>)).toList();
    } on FormatException catch (e) {
      // JSON解析失败，说明文件被破坏，兜底返回空列表并备份坏文件
      await _file.copy('${_file.path}.backup');
      return [];
    }
  }

  Future<void> saveRecords(List<Record> records) async {
    final tmpFile = File('${_file.path}.tmp');
    final jsonStr = jsonEncode(records.map((e) => e.toJson()).toList());
    await tmpFile.writeAsString(jsonStr, flush: true);
    await tmpFile.rename(_file.path);
  }
}

这里有两个关键设计值得展开。

第一是jsonDecode外层的try-catch。文件存储方案的天敌就是"文件存在但内容已损坏"。可能是用户用第三方文件管理器手动编辑过，也可能是写入过程中电量耗尽。不管原因是什么，崩溃是绝对不可接受的。我的做法是：解析失败时先把坏文件复制一份备份，再返回空列表，至少保证App能启动，用户的坏数据还有机会被恢复。

第二是flush: true参数。writeAsString默认可能有系统级缓存，数据不一定立刻落到磁盘物理区。给flush传true可以强制刷盘，虽然会多损耗一点点性能，但对数据的持久性保证要强很多。记账类App的数据重要性很高，这点性能损耗完全值得。

3.3 数据流与状态管理闭环

有了存储层，接下来要解决的是"界面上的数据从哪里来、变化后到哪里去"的问题。在Flutter MVP里，我选择了最轻量级的方案：ChangeNotifier加ValueListenableBuilder，没有引入provider或riverpod这类状态管理框架。

原因很简单：MVP只有一个页面加一个弹窗，全局状态只有一个List<Record>和一个"当前选中的分类"。用重型状态管理框架纯属杀鸡用牛刀。App启动时从FileRecordStore.loadRecords()加载数据，放入一个RecordController中；每次用户添加或删除账目时，先更新内存中的列表，再调用saveRecords()将最新列表写回文件。

这里有个顺序问题非常容易踩坑：到底是先改内存还是先写文件？我的经验是，先改内存并刷新界面，再异步写文件。这样用户操作后的界面反馈是即时的，不会因为文件写入的几十毫秒延迟产生卡顿感。文件写入失败的可能性极低，万一失败了，下次启动时从文件读到的还是之前的数据，用户最多是感觉"上次记的账没了"，而不是"App卡住了"。在MVP阶段，流畅的交互体验优先级远高于数据一致性。

3.4 界面与交互的完整闭环

MVP的界面我做得非常朴素：一个列表页 + 一个添加记账的底部弹窗。列表页顶部放分类筛选的横向滑动标签，中间是账目列表，右下角是悬浮的添加按钮。这些交互用Flutter的ListView和showModalBottomSheet就能实现，没什么好吹的。

真正需要打磨的是"记账后的即时反馈"。我加了一个小功能：记完一笔账之后，列表顶部的"本月支出"数字会伴随一个动画更新。这个动画本身逻辑很简单，就是几行AnimatedSwitcher的代码，但它让整个MVP的"完成感"提升了一个档次。内测用户里好几个人都提到了这一点，说"用起来像一个完整的产品，不是demo"。

这也印证了我一直以来的一个观点：MVP的质量不是由功能数量决定的，而是由核心路径的完成度和细节体验决定的。一个只有三个功能但每个都很顺滑的App，比一个功能很多但处处半成品的状态要好得多。

4. 实测遇到的问题与排查复盘

4.1 三大高频问题的排查实录

整个开发过程中，我遇到的最典型的问题有三个，每一个都值得单独说。

第一个是Android模拟器上getApplicationDocumentsDirectory()偶发抛异常。排查后发现是因为我在测试时切换了模拟器的系统语言，导致应用沙盒路径初始化时触发了一个系统目录变化的bug。解决方案很粗暴也很有效：在存储层初始化外面加一层兜底，异常时降级到getTemporaryDirectory()目录并弹一条日志。虽然临时目录的数据可能被系统清理，但至少测试环境不崩，正式设备上这个异常几乎没有出现过。

第二个是中文乱码。用文本编辑器打开生成的records.json时，中文备注显示为\u4e2d\u6587。一开始我以为写坏了，后来才意识到这是jsonEncode的默认行为：默认不转义非ASCII字符，但Dart的JsonEncoder有个构造函数参数可以控制。实际写文件时我改用const JsonEncoder.withIndent(' ')，中文就正常展示了。这个问题的根源是"程序运行正常但不能方便地人类可读"，在调试阶段非常致命，因为你看不清数据到底存了什么。

第三个是频繁写入导致文件内容偶尔丢失。这个问题的根源就是我在2.3小节里提到的原子写没有做。前几个版本我图省事，直接writeAsString到正式文件，结果在反复快速添加删除操作时，偶发出现了"文件写了一半"的情况。认真实现临时文件加rename之后，这个问题再也没出现过。这个教训让我彻底明白了一件事：File-Based方案的许多"坑"，本质上都是"没有用足够严谨的工程手段去管理文件"造成的。

4.2 File-Based方案速查对照表

整理一下我对File-Based方案的理解边界，方便大家快速判断自己的项目适不适合。

这张表不是绝对的，但按照它来选型，大部分情况不会出大错。

4.3 从MVP到成熟产品的演进路径

项目做到内测阶段，我对后续演进方向有了更清晰的认识。如果这个MVP被验证，下一步不是直接替换掉File-Based存储，而是在现有架构上逐步演变。

第一个演进方向是文件分片。把records.json按年月拆分成records_2024-01.json、records_2024-02.json，这样单文件体积不会持续膨胀，加载历史数据也可以做成懒加载。这个改动只影响存储层内部，对上层接口完全透明。

第二个演进方向是引入SQLite。当用户发现自己一年能记几千条账目，且开始需要"每个月每个分类平均花了多少"这种复杂查询时，数据库的优势才真正体现。这时候因为我已经把存储与UI解耦，替换的成本其实不高。但注意，不要一上来就做这个优化，你永远不知道用户的真实使用习惯是什么样的。

第三个演进方向是数据导出与备份。File-Based方案在这里有天然优势：直接把JSON文件复制走就是完整的备份。我在MVP里预留了一个"导出数据"按钮，测试阶段甚至可以用来做用户调研——看用户愿不愿意导出自己的数据，从侧面验证数据对用户的价值。

5. 再三叮嘱的几个细节

最后分享几个每次做文件存储项目我都会提醒自己注意的细节。

第一个是永远不要相信"文件一定存在"。文件可能存在但内容为空、存在但内容损坏、不存在、存在但路径不对，这四种情况都要在代码里处理。我在loadRecords()里把所有异常分支都覆盖了一遍，测试时专门用坏文件验证，确保App在极端情况下不崩溃。

第二个是要给JSON文件的版本留后路。我在settings.json的第一行固定写入一个version字段，值从1开始递增。将来如果数据结构变化，老文件可以据此做迁移。现在不写版本号，等到用户已经有真实数据了再改结构，那就是给自己找坑。这不花什么成本，就是一个字段的事，但很多做文件存储的项目都会忘了它。

第三个是善用系统文件管理工具测试。开发阶段我把records.json所在目录暴露给Android系统的文件管理器的"浏览内部存储"入口，这样我可以随时修改文件来模拟各种异常情况。这个习惯帮我提前发现了好几个边界条件的bug，强烈推荐。

根据我个人的体会，File-Based方案做MVP最妙的地方在于，它强迫你把"存储"这个抽象层级放得很低。没有数据库帮你兜底，你就必须自己认真对待每一次读写、每一次序列化、每一次异常兜底。这些经验对做更复杂的项目同样适用。即使有一天你在正式产品里用了数据库，那些被File-Based项目锻炼出来的对数据边界、原子写入、异常恢复的意识，是切实的行业基本功。