“我需要一个数据库，这样以后可以查询订阅数据。”说这话的时候，我距离撕掉键值存储、换成真正的数据库，只差最后一步。理由听起来很负责任，但现实是：我一分钱用户都没有，根本没什么数据可查。就为了给空盒子修个仓库，我差点搭进去一整天的工作量。

事情的起点很简单。我做的浏览器扩展有付费版，验证逻辑跑在 Cloudflare Worker 这个小服务上，只存一种数据：给你一个邮箱，告诉我这个人订阅没。也就是 email → { active, plan, periodEnd } 这一个键值对，查一次主键，还一条记录，没有连接、没有报表、没有“上个月流失了多少用户”这种问题。靠 Cloudflare KV 一行代码就搞定，一分钱不花。

打开网易新闻 查看精彩图片

可念头还是爬上来了——“万一以后想看全部订阅者呢？按月算收入？看看谁快到期了？KV 做不了这些查询，趁现在体量小，应该直接上真正的数据库，免得以后迁移。”就是这句“免得以后迁移”，让我这样独立开发者说服自己，去建一个根本没人要的东西。眼看就要用上线数据模式、SQL、按行计费的重量级存储，只为服务一套我压根不会看的报表，服务一群压根不存在的客户。

好在两件事把我拽住了。第一，我担心的那些报表早就有了，而且有人替我维护，就是 Stripe 控制台。按月收入、活跃订阅数、流失、续费到期、MRR，全列得清清楚楚，一支专业团队打造，免费，比我将来在自己的数据库上手搓的任何报表都强。当我觉得“得查查自己的数据”时，忘了付费本就跑在 Stripe 上，而 Stripe 本身就是查询层。我想知道的 90%，不过是已经打开的那个标签页而已。

第二，“避免迁移”没错，但我差点制造的迁移，比原本要躲的那个贵得多。现在就 KV 换库，意味着存储和支付逻辑要同时改，两个变量一起动，出错点翻倍，还赶在发布前。而等到将来真的受够了 KV 的局限，到那时我再迁移，用那会儿经过真实用户请求打磨出的表结构和查询需求来动手——“靠认知迁移”远胜“靠猜测现在迁移”。

于是我留住了 KV。整个犹豫期只浪费了二十分钟的纠结，而不是一整天的重写，产品也将凭着那个已经跑通的简单方案发货。过后复盘，发现自己不知不觉把“想造个厉害版本”包装成“我在为未来负责”。面向未来的直觉算不上全错，但在零用户的阶段，几乎每一句“我以后会用到”都只是猜测。而猜测，是一个人能写出的最昂贵的代码——你得永远维护它，而它从来没被需要过。

现在我给自己定了个测试：这件事，到底是在解决一个我真实遇到的麻烦，还是在解决一个我想象中、未来版本的我才可能遇到的麻烦？如果答案是后者，而且今天就得付出真实成本，那就不做。记下来，然后继续往前走。一个连产品都没发布的人，最该囤的不是数据库，而是落地。