自己用的小工具跑得挺爽的，想开放出去让别人也能用，第一反应通常是——「工程化之后，我改起来是不是就没这么爽了？」
这个担心是合理的，但麻烦的地方跟大多数人以为的不一样。
会变麻烦的部分
诚实说，有四件事回不去了：
| 现在（自己一个人用） | 产品化后 |
|---|---|
| 改完存盘，浏览器刷新就看到 | 改完要 build → push → 等部署 |
| 改错了 Cmd+Z 或回滚单文件 | 改错了要回滚 commit、重新部署 |
| 数据结构随便加字段 | 加字段要写迁移，考虑老用户的库版本 |
| 只有你一个用户 | 有真实用户后，你不能再随便丢数据 |
最麻烦的是最后两行。它们是本质变化，不是工具问题。
不会变麻烦的部分
但下面这些其实不变：
- 提需求、开工、看效果的日常循环没变，因为 dev server 的 HMR 秒刷跟以前一样
- 代码按模块拆开之后，改一个板块只需要碰几个小文件，出错面反而小、review 反而快——如果你原来是几千行单文件，拆完之后迭代其实更快了
真正拖慢你的是三件事，跟工程化本身无关：
- 反馈会进来 —— 不再是「我觉得不对」，而是「20 个陌生人各有各的不对」，需求排序本身变成工作量
- 不能再随便改数据结构 —— 一个人用的时候档随时能重建，别人的数据在里面时，每次动 schema 都要写迁移 + 测试
- 反馈渠道要人管 —— GitHub issue、留言、邮件，这些是持续开销
一条实际能用的规矩：快改与慢改分开
产品化之后我建议引入一条规矩：「快改」和「慢改」走两条不同的路。
- 快改：UI 调整、文案、样式、按钮位置。当天上线，跟原来一样。
- 慢改：数据 schema、存储层、任何会影响老用户已有数据的东西。必须先写迁移，再写测试，再确认。
这样日常「这个按钮挪到左边」的需求速度不变。只有真正动骨头的时候才慢下来——而那种事本来就该慢。
一句话可以概括：产品化不会让改按钮变慢，只会让改数据变慢。而改数据本来就该慢。
附：迁移，宁早不晚
顺带说一条相关的：如果你正在犹豫要不要把存储从 LocalStorage 换到 IndexedDB（或者任何一次大改数据层的操作），用户越少越早做越好。
现在做只需要照顾你自己的一份档；等有 50 个用户了再做，得处理 50 种历史状态。而且做迁移时至少守住这几条：
- 迁移后旧数据不要删，只打一个「已迁移」标记——这是你的回滚生命线
- 幂等，跑多次不会重复导入
- 失败要整体放弃，回退到旧存储继续跑，绝不出现「新的挂了 + 旧的也读不了 = 白屏丢档」
- 新存储不可用要能自动降级（隐私模式、老浏览器都会遇到）
- 写单测：迁移幂等 / 逐字段比对不丢数据 / 空档 / 失败回退 / 降级，全都真跑一遍
看起来啰嗦，但少一条你都可能在某个凌晨收到「我的数据没了」的邮件。用户的数据不是可选项。
马启航Marvis