DEV Tab 这扩展，功能本身我不打算多聊——新标签页替换信息流、过滤标签、活跃度热力图，哪个不是浏览器扩展里的熟脸？属于一个开发者该有的基本盘，做顺了是应该的，没什么可夸。真正有意思的是它那个“无后端”的设计：没有统计埋点、没有追踪、密钥就放在浏览器本地存储里，只在需要认证的时候直连 DEV。然后评论区就炸了，39 条讨论，一群人围着“密钥放本地、没有后端”这件事，替作者把该算的安全账、成本账、认知账全算完了。这比扩展本身更像一份免费的商业尽调。
说句扫兴的，无后端放在 2026 年，早就是小工具圈的政治正确了。你不上云端，大家默认你靠谱；你上一个后端，评论区先问你为什么。这已经不是卖点了，是及格线。但及格线归及格线，真要把它当成“护城河”来夸，就有点没算清账了。无后端从来不是壁垒，它只是成本结构的选择——谁都能无后端，只要作者愿意放弃统计、放弃跨设备同步、放弃商业化里最好用的那套用户画像。代价作者自己也没藏着：速率限制摆在那，重度使用触顶了只能拿缓存兜着，给你看旧内容，外加一句提示。用户短期能接受，因为免费嘛。长期看，这就是个隐形的产品天花板，只是现在还没人撞上去。
评论区为什么夸得挺狠？其实是认知差在起作用。普通用户看到“本地保存，不上传”，第一反应是“这作者老实、尊重隐私”；懂架构的那几位读者看到的是另一笔账——凭证放请求头而不是 URL、权限最小化、断开连接清除缓存。这帮人相当于把作者的技术底裤当场验了一遍，结论是：行，这裤衩穿得正。但你要是问我这笔账到底值多少钱，我会说，短期是信任红利，长期是限制条件。同一个设计，两种算法，得出的估值差着两个数量级。
我不觉得作者做错了。在一个没有商业野心的免费小工具里，无后端是最合理的账：不用维护服务器，不用背数据合规，不用半夜担心数据库泄露。这笔账对独立开发者特别友好，省下的每一分钱都是真省下的，因为本来也没多少流量需要规模化。很多人做这种“只在某个社区里有名字”的工具，死就死在后端维护成本超过它带来的那点名气收益。作者这一刀切下去，账算得过。我做这种小工具的时候也这么选，省事，睡得着。
但麻烦在后面。一旦这扩展被 DEV 官方注意到、被推到更大的台面上，“无后端”这个卖点就会开始反噬。为什么？因为功能会倒逼架构。你想做消息通知、做个性化推荐、做跨设备同步，甚至只是想在服务器端做一层接口聚合来规避速率限制——任何一条真正有用户价值的功能，都会把“无后端”从优势变成绊脚石。真到那一步，作者面临的选择就不是“要不要加后端”了，而是“加了后端，早年间积累起来的信任怎么解释”。用户可不管你这后端是不是只做缓存，用户只知道：以前你说密钥不出本地，现在你开服务器了。这笔信任账，转头就给你刻在产品墓志铭上。
所以我的判断有两层。第一层，现阶段无后端是对的，甚至是唯一明智的账。第二层，如果作者真把它往“能赚钱的持续产品”方向推，无后端会是最早被推翻的那个决定。这中间有个窗口期，窗口期里免费、开源、本地密钥、无后端这四样叠在一起，能换来一批忠实的早期用户和一个干净的口碑。窗口期一过，功能需求上来，架构必须改，那时候怎么平滑地改而不把自己原来的口碑砸了，才是真考验。
那怎么办？只留一条窄路：把无后端做成产品里可解释的一部分，而不是一个永远不变的卖点。作者路线图没定，倾向先看反馈。这态度我反而喜欢，至少没在没看懂用户怎么用之前就急着扩功能。现在就两条线都留着——本地密钥和无后端是基本盘，任何可能引入后端的功能先放风，看社区反应。社区能替你把功能排序排出来。真到了用户喊破嗓子要通知、要跨设备那天，你再上后端也有话可说：不是你要破承诺，是需求压过来了。这解释未必人人买账，但总比闷声加个后门强。
最后这账落到一个更冷的地方：DEV Tab 这种扩展，最终大概率不会变成一门生意，也不太该变成一门生意。它更像一个开发者用几天时间做了个工具，顺手把架构判断公开给社区看，社区顺手帮忙做了评审。真说值钱，也就是这份公开评审的过程——让其他想做社区工具的人少走一遍“后端到底上不上”的弯路。这笔账，作者已经赚到了，只是这钱不进账本。咱下篇见。