free-for.dev 不只是省钱清单：把免费层当成基础设施候选池

“白嫖”叙事掩盖了真正的工程问题

开发者看到 free-for.dev，第一反应往往是把它当成省钱工具：把付费 API 换成免费 API，把生产部署迁移到免费托管，把监控、日志和存储全部拼起来。对早期原型来说，这种方式确实能降低试错门槛；但项目一旦有真实用户，免费层就不再是福利，而是一个需要被管理的外部依赖。

这个 GitHub 仓库的定位比社交媒体上的“免费服务大全”克制得多。它收录的是对系统管理员、DevOps 和基础设施开发者有用的 SaaS、PaaS、IaaS 免费层，README 说明条目来自 1600 多人的 Pull Request、审阅和维护。GitHub API 当前显示仓库约 130K Stars、最近仍有更新。换句话说，它适合用来发现基础设施选项，不适合替你确认某个服务今天的价格。

清单的价值在于覆盖面

一份工程项目需要的服务，分散在很多产品类别里：代码仓库、CI/CD、构建制品、部署、DNS、CDN、对象存储、数据库、邮件、认证、监控、日志、测试和安全。单个供应商的官网通常只介绍自己的产品，搜索引擎则会优先展示推广内容。free-for.dev 把这些候选放进同一张目录，能让开发者看到一条完整交付链上还有哪些替代节点。

但覆盖面越大，误读风险也越高。一个项目列出 60 多个类别，并不代表你应该每类都注册一个账号。服务数量越多，权限、密钥、告警、账单、数据保留和故障排查都会变复杂。清单最适合在架构早期提供候选，在迁移阶段提供备选，在季度复盘时提醒团队重新核对条款。

按风险而不是按“省了多少钱”排序

可以把候选服务分成三层。第一层是低风险的开发辅助工具，例如预览部署、临时构建、测试环境和公开静态资源；它们的主要风险是额度耗尽和项目暂停。第二层是可替换的运行服务，例如静态托管、边缘函数、基础监控和非关键日志；这里要准备构建产物、配置导出和域名迁移。第三层是承载用户数据、认证、邮件、支付或业务数据库的核心服务；免费只是成本因素，数据处理、备份恢复、合规和故障切换必须先过关。

这种分层比“每月省 500 元”更可靠。免费层一旦改变，低风险服务可以换，核心数据服务却可能需要数周迁移。尤其是认证、邮件和数据库，供应商锁定往往不在报价单里体现。

免费额度要连同条件一起记录

README 中的条目可能写着请求数、构建分钟、日志容量或存储上限，但完整判断至少需要补充六个字段：适用地区、资格要求、重置周期、超额处理、数据保留和导出方法。还要记录核验日期，因为免费层会调整。Cloudflare、Deno Deploy、Sentry、OpenObserve、CircleCI、Netlify、Vercel 等服务都应回到官方计划页面确认当前条件。

尤其要警惕三种措辞：免费试用可能在几天或几个月后结束；always free 可能只覆盖某一资源和区域；“无需付费”可能不等于无需绑定支付方式。对个人项目，这些差异或许只是注册时多一步；对团队项目，它们会变成预算、权限和上线风险。

把发现清单变成落地流程

比较候选时，先写一个最小运行场景，而不是直接迁移整个项目。部署服务跑通构建、失败回滚和域名绑定；API 服务记录正常响应和限流响应；日志服务检查字段、延迟和过期策略；存储服务做一次导出和恢复。只有这些行为可解释，额度数字才有意义。

同时保留退出材料：本地构建命令、环境变量清单、数据库 schema、导出脚本、DNS 记录、监控规则和密钥轮换步骤。免费层的最好用法，是让你以很低成本验证一个方案，而不是让你的项目永远依赖某个“今天还免费”的入口。

给个人开发者和团队的结论

个人开发者可以把 free-for.dev 当成一个高质量书签库：先从免费层开始验证想法，再在项目有收入或稳定流量后重新评估。团队则应该把它纳入供应商管理流程，核验条款、控制用量、设置预算保护，并保留迁移路径。

如果要引用具体额度，请同时标注官方链接和核验时间。清单能帮你少走发现服务的弯路，但不能替你承担条款变化、数据保护和生产故障的责任。