开发者免费服务清单的正确打开方式：别只看额度，先看退出成本

真正难找的不是免费服务，而是免费层的边界

“开发者免费服务清单”很容易变成一篇额度摘抄：云厂商给多少小时，监控平台给多少事件，部署平台给多少构建分钟。问题在于，这些数字离开资格条件、地区、计费开关和超额处理方式之后，几乎没有决策价值。free-for.dev 值得关注的地方，是它把分散在 SaaS、PaaS、IaaS 产品页里的免费层组织成了一个可检索的基础设施索引。

仓库 ripienaar/free-for-dev 当前由 GitHub API 显示为约 130K Stars，描述明确限定在 DevOps 和基础设施开发者会用到的服务。README 由 1600 多人的 Pull Request、审阅和维护积累而成，并明确区分免费层与免费试用，也把安全条件纳入收录标准。它的价值不是替你做选型，而是缩短发现候选的时间。

先把“免费”拆成五个问题

看到一个条目时，先不要问额度有多大，而要问五件事。第一，免费资格是无条件的，还是需要信用卡、手机号、组织验证或特定地区？第二，免费层是永久存在，还是仅在注册后十二个月有效？第三，额度按用户、项目、组织、请求、带宽还是时间计算？第四，超额后是停止服务、限速、保留账单还是自动升级？第五，数据和配置能否在不依赖供应商控制台的情况下导出？

这五个问题会把“免费服务”从营销标签变成工程约束。一个每月有足够请求量的 API，如果超过额度就直接返回 429，可能仍然适合个人工具；但如果它会自动切换付费计费，团队就必须先建立预算保护。一个存储服务如果价格很低，但导出速度慢、对象元数据不完整，也未必是好的长期依赖。

这份清单覆盖的不是一条产品线，而是一张交付图

README 的目录从主要云厂商的 always-free 限额延伸到 API、数据与机器学习、制品仓库、CI/CD、测试、安全与 PKI、认证授权、日志、监控、崩溃处理、邮件、DNS、IaaS、托管数据、隧道、对象存储、地图、支付和 Web Hosting。分类数量很大，但工程师不应该把它理解成“每一类都找一个”。

更合理的做法是沿项目生命周期看：代码从哪里托管，如何构建，构建物在哪里部署，运行数据放在哪里，错误如何被发现，域名和证书如何管理，用户认证由谁承担，最后如何迁移。免费层清单在这里的作用类似候选池，真正的架构仍需要围绕数据、权限、可观测性和退出路径来设计。

一个可复用的评估模板

可以为每个候选建立一行记录，字段包括：服务名称、官方计划链接、核验日期、区域、账号类型、信用卡要求、免费资源、重置周期、硬性上限、超额行为、数据保留、导出方式、替代方案和当前用途。不要只保存“每月 10,000 次”这样的孤立数字，必须把数字与适用条件绑定。

随后做一轮最小实测。部署类服务至少跑通一次构建、失败重试、回滚和域名绑定；API 类服务记录正常、限流和鉴权失败三种响应；日志类服务验证事件是否延迟、字段是否被截断、过期数据能否导出；数据库和对象存储要测试备份恢复，而不仅仅是能否写入一条记录。免费层最容易在边缘行为上暴露真实成本。

如果候选进入生产，还要增加两层保护：一是对用量设告警，阈值应低于计划上限；二是保留最小迁移材料，包括 schema、导出脚本、部署配置、域名记录和密钥轮换记录。免费并不意味着不需要运维。

不要把社区清单当作实时价格接口

free-for.dev 是社区维护的索引，服务商才是条款的最终来源。像 Cloudflare、Deno Deploy、Sentry、OpenObserve、CircleCI、Netlify 和 Vercel 这样的条目，计划名称、配额、地区条件和商业限制都会变化。云厂商的“永远免费”也常常只覆盖某个实例类型、区域或资源用量。文章和 README 的数字只能帮助你发现候选，不能直接写进预算表。

还要区分自托管与托管免费层。清单的纳入范围主要是 as-a-Service，不是“所有能自己部署的软件”。一个项目有开源仓库，并不表示它的官方云服务、团队功能或商业支持也免费。部署决策需要分别核对许可证、托管条款、数据处理方式和服务等级。

最后的判断标准

对个人开发者，免费层的最佳用途是降低原型验证成本；对小团队，它可以帮助建立一条低成本但可替换的交付链；对生产系统，它最多是一个容量明确、风险可接受的起点。只要项目开始承载用户数据、支付、邮件或关键业务，就应该把计费、导出、备份和替代方案放进同一个评审里。

因此，free-for.dev 最值得保留的不是某一个额度，而是一种工作方法：先用索引发现服务，再用官方页面确认条款，用小规模测试验证行为，最后把供应商依赖写成可迁移的工程资产。