免费+付费到底应该怎么设计？
10015.io 有 50 多个工具，几乎全部在浏览器里执行、极少请求服务端，它把这些工具全部设为免费，靠 AdSense 补回约 300 美元的 MRR。TinyWow 有 250 多个工具，同样免费开放，只在上层挂了一个 $5.99/月的会员。Omni Calculator 估算 1429 万访问，全站免费，收入全部来自展示广告。
TinyWow 首页把工具收进 PDF、Image、Video、AI Write、File 五个入口，卡片上标的工具数量从 10+ 到 45+ 不等。
三家的免费范围几乎一样宽，下刀的位置完全不同。
把这口气理顺之后，免费层不再是一个道德问题，而是一道记账问题：哪一部分成本由你承担，哪一部分由掏钱的人承担。
刀口画在成本曲线上，而不是功能清单上
最常见的错法是按"这个功能高级、那个基础"来划线。用户不会这么理解，他们只会问一句：这么简单的东西凭什么收费。
换成成本视角，划线立刻有了依据：边际成本接近零的部分免费，每多一次调用都要烧资源的部分收费。10015.io 之所以能大方，是因为它的工具几乎不占服务器；反过来，凡涉及上传、排队、转码的环节，每一次调用都在掏钱，免费额度必须在这里截止。
把重计算通过 WebAssembly 压进浏览器，等于把整条成本曲线往下平移一档，原本必须收费的功能就此落进免费区。这也是为什么同样扛着每月两百万次访问，有的站活得下去，有的站只是在替机房打工。
这条思路还能反过来用：如果某个功能无论如何都压不到客户端，比如要用到只能在服务端跑的模型或大量历史数据，那它就不该出现在免费层里，哪怕它看上去很基础。
限次数还是限功能，取决于用得有多急
Gusto 的免费时薪工资计算器不做任何限制：对应词 wage calculator 搜索量 17000，月访问约 17776，来的人都在核算员工薪资，Gusto 卖的是后面的代发薪服务。Shopify /tools/ 下的利润率计算器峰值月访问超过 2 万，同样全免费，卖的是开店之后那一整套。
这类页面如果在中间弹一道注册墙，等于把最有价值的线索赶走。它们的免费层要点是"不留门槛，留钩子"：结果页直接给出下一步要用的东西，而不是拿半个结论去换一个账号。
这一层的验收标准很朴素：用户在两分钟内拿到完整结果，并且清楚知道哪些内容不需要付钱。一旦他需要猜，页面就已经输了。免费部分给得越痛快，付费部分反而越好卖，原因就在这里——用户已经用结果确认过这个页面值得信任。
再看 TinyWow 的 $5.99 会员：它限的是体验，免广告、更大的文件、批量处理，而不是结论。对那种一年用三次、每次都很急的需求，限制文件大小和并发数量，比限制"能不能看到结果"更不容易激起反感。刀切在结论上，用户会记住这次不愉快，下次直接搜别人。
免费额度不能只在前端数
额度一旦能被重置，付费的意义也就跟着塌了。真正的计数要落在服务端的一张用量表上，按账号或设备标识记下次数与周期起点，跨设备时才可能保持一致。
这一步注定会被人绕过去。常见的心态是"反正额度写在代码里，一般人不会去翻"，可清理浏览器数据、换台设备、开隐私窗口这三件事每天都在发生，而且都属于正常使用行为。
从设计上，免费额度还应该跟时间挂钩：按月重置比一次性发放一批次数更贴近真实使用节奏，用户也不会为了攒额度而刻意拖着不用。
这件事交给 SQLite 足够撑很久：写入是本机文件 IO，延迟按毫秒算，单表几十万行的计数更新毫无压力，备份也只是复制一个文件。把额度逻辑和授权判断放在一起，后面要加"付费用户不清零"这类规则时也只用改一处。
服务端既然要记账，顺手把用户做过的每一次调用写进事件流，日后想看"哪一类请求最烧钱"时就有依据了，不必再去翻网关日志做猜测。
会员的那笔钱也要记得算准
五点九九美元乘以用户数，听着是小学算术，落到代码里却是最容易留坑的地方：浮点累加会攒出分位误差，跨币种结算又会引入新的舍入规则。金额用 decimal.js 存定点数，账单周期的前后时间比较用整数时间戳，这些约定在项目一开始就定下来，比事后查账便宜得多。
等到工具攒到一定数量，整个站点会长成一批在线工具集合的形态：免费层负责被记住，付费层负责把最贵的那部分算力收回来。两条线各管一件事，界面上的按钮才不会互相打架。
说到底，会员层卖的不是功能开关，而是容量与时长的确定性。把这句话直接写进产品说明里，用户理解的速度比看任何价格对比表都快。
把这些放在一起，划免费层这件事其实很朴素：先把每个功能调用一次的真实成本列出来，再决定哪些该免费。剩下的交给数据——如果免费层来的人里有相当一部分第三次打开了同一个工具，那才轮到考虑往上加付费按钮。
数据来源：10015.io、TinyWow 定价与工具数量来自各自官网公开信息；Gusto、Shopify、Omni Calculator 流量为第三方估算。