北京
“我离删掉键值存储、换上一个真正的数据库只有一步之遥。”一位独立开发者复盘自己前不久的一段心路历程，几乎所有精力都被一句话牵引——“我以后会想查询订阅数据的。”然而真相是，他一个用户都没有。
他的浏览器扩展付费层级，靠一个轻量级 Cloudflare Worker 做验证。存的东西简单到不能再简单：给定一个邮箱，这个人订阅了没有？每个邮箱只对应一条记录，没有表关联、没有复杂报表，更不需要回答“上个月哪些人流失了”这类问题。用 Cloudflare KV 这类键值存储，一行代码就搞定，成本为零。
问题出在那个念头：“如果我想看到所有订阅者呢？月度收入、谁快到期了？KV 做不了这些查询。最好趁现在早换真正的数据库，省得以后迁移。”在独立开发的世界里，“省得以后迁移”这句话，几乎是说服自己建造别人压根不需要的东西的头号话术。他差点用一个更重的方案——建表、写 SQL、按行计费——替换一套运行良好、零维护的免费存储，去服务一份没人在看的报表，面向那批还不存在的客户。
关键时刻，两件事把他拦住了。第一，他担心的那套报表早就有人做好了，而且维护这家的人根本不是他。那是 Stripe 后台。月度收入、活跃订阅、谁到期、谁该续费、MRR——全都在那里，一个团队免费开发出来，远比自己手搓要好。他曾忘记了，付款走的是 Stripe，Stripe 本身就是查询层。想知道的 90%，其实就在一个已经打开的标签页里。
第二，不动手反而更划算。KV 换成数据库，意味着功能和逻辑未验证就要同时动存储和支付两条线，踩坑概率翻倍。而如果真有一天 KV 不够用了，等到手握真实用户的数据和需求再迁移，清清楚楚知道该建什么表。“带着知识再迁移”远比“带着猜想来折腾”聪明太多。
最终，他保住了 KV。整个纠结耗费 20 分钟，而不是一整天的重写。产品依旧跑在那套简单且已经跑通的方案上。
他提醒自己，也提醒其他独立开发者，有一个模式反复出现：把“我想建个花哨版本”的冲动，包装成“我在为未来负责”。“面向未来”的直觉有时确实是对的，但在零用户时，几乎所有“我以后会需要这个”都只是猜想。猜想的代码，是最昂贵的那一类——因为它们要被永远维护，却从未被真正需要。
他给自己定下一个检验标准：这究竟是在解决当下的问题，还是虚构出一个未来版本的自己去解决的问题？如果答案是后者，且今天要付出的成本实实在在，那就不做，记下来，继续往前走。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
