用文件系统分支配合枚举类管理本地状态，核心是将状态语义与存储路径对齐：每个枚举值绑定唯一路径（如PENDING→./data/pending/），封装getStoragePath()方法；按状态分目录实现原子操作；辅以.meta.json记录流转元数据；枚举内置校验逻辑防非法跳转。
用文件系统分支配合枚举类管理轻量级项目的本地状态，核心是把“状态语义”和“物理存储路径”对齐，让代码可读、可维护、可调试。不是简单地把数据塞进文件，而是让每个状态有明确的落盘位置和行为边界。
状态枚举定义要覆盖全生命周期
枚举不只是打标签，它要承载状态语义和路径逻辑。比如一个任务项（Task）可能有 PENDING、IN_PROGRESS、COMPLETED、ARCHIVED 四种状态。不要用字符串硬编码，而是定义成带路径前缀的枚举：
-
PENDING → 对应
./data/pending/ -
IN_PROGRESS → 对应
./data/active/ -
COMPLETED → 对应
./data/completed/ -
ARCHIVED → 对应
./data/archive/
这样，状态切换时只需移动文件或更新元数据，无需额外查表或写条件判断。枚举类中可封装 getStoragePath() 方法，统一返回对应目录，避免散落的路径字符串。
文件系统分支按状态隔离，天然支持原子操作
每个状态目录就是一个独立分支，好处很明显：
- 新增任务：直接写入
pending/目录，不干扰其他状态数据 - 开始处理：把文件从
pending/移动到active/，操作系统级原子移动，无竞态 - 完成归档：先复制到
archive/，再删active/中原文件，保留审计痕迹 - 批量清理：清空
pending/或archive/即可，不用遍历全量数据加条件过滤
这种设计在 Electron、Tauri 或桌面 CLI 工具中尤其实用——Node.js 的 fs.rename() 或 fs.cp() 能直接支撑，无需数据库事务。
配合元数据文件实现状态增强
单靠目录还不够。建议每个数据文件旁配一个 .meta.json，记录状态变更时间、来源动作、旧值快照等。例如：
task-123.json.meta
meta 文件内容示例：
{
"state": "COMPLETED",
"updatedAt": "2026-06-07T10:22:45Z",
"fromState": "IN_PROGRESS",
"version": 3
}
这样既保持主数据文件轻量（纯业务 JSON），又让状态流转可追溯。枚举类可提供 onTransition() 钩子，在状态变更时自动写入 meta，把逻辑收口。
避免常见陷阱
实际落地时容易踩几个坑：
- 别把所有状态都映射为目录——像 DELETED 状态更适合走软删除标记 + 定期清理，而不是单独建
deleted/目录（易被误恢复） - 路径拼接必须用
path.join()，不能字符串拼接，否则跨平台出错 - 首次启动时检查各目录是否存在，自动创建，不要假设环境已就绪
- 状态枚举的顺序不重要，但状态流转规则要显式声明（比如禁止从
ARCHIVED直接回到PENDING），可在枚举中加canTransitionTo()方法校验
