free-for.dev 深度用法：开发者免费层清单，怎样变成可替换的基础设施方案

免费服务清单最有用的部分，不是“免费”

开发者经常把 free-for.dev 当成一张省钱表：打开页面，找一个有额度的 API、数据库或部署平台，复制链接，注册账号。这样的用法很快就会失效。免费层会改规则，地区和身份会影响资格，试用期也常常被误读成长期免费。真正有价值的，是把这份由社区维护的清单当作基础设施选型的入口，再回到供应商的官方价格和限制页面完成核验。

仓库目前由 GitHub 用户 ripienaar 维护，GitHub API 显示它的默认分支是 master，描述定位在 DevOps 和基础设施开发者的 SaaS、PaaS、IaaS 免费层，最新推送时间为 2026 年 7 月 28 日，公开仓库约有 130K Stars。它不是某一家云厂商的产品目录，也不是承诺“永远不收费”的合同，而是一份有明确纳入标准的社区索引。

先理解它的筛选标准

free-for.dev 的 README 明确把范围限定为面向基础设施开发者有用的 as-a-Service 服务，不以自托管软件为主要对象。进入清单的服务需要提供免费层，而不只是短期试用；如果免费层按时间桶计算，维护者倾向于要求至少覆盖一年。清单还强调安全边界，例如不能把 TLS 只留给付费层。这些规则让它比随手收集的“免费资源大全”更可用，但并不能代替今天的官方条款。

仓库内容按云厂商、API 与数据、CI/CD、测试、安全与 PKI、认证、日志、监控、邮件、DNS、IaaS、托管数据库、对象存储、支付和部署等分类组织。分类本身就是一个架构提醒：一个小项目需要的并非“最多服务”，而是能组成一条可替换的交付链。

把清单改造成项目决策表

第一步不是注册，而是先写出项目的硬约束：部署区域、是否需要信用卡、是否允许绑定支付方式、数据能否出境、是否需要 SLA、团队人数、峰值流量、日志保留期和迁移能力。然后从清单里挑出两到三个候选，不要只看额度数字。

第二步是把每个候选拆成四类信息：资格条件、用量上限、超额行为和退出成本。资格条件包括个人/组织账号、地区、验证方式和是否需要信用卡；用量上限包括请求次数、构建分钟、存储、带宽、观察量和保留期；超额行为要区分硬性拒绝、降速、自动转付费和要求升级；退出成本则要看导出格式、域名迁移、镜像迁移、数据库兼容性以及日志能否取回。

第三步才是做小规模实测。一个静态站可以测一次完整构建、缓存命中、回滚和自定义域名；一个 API 服务要测限流响应、错误格式和计费告警；一个监控服务要确认告警延迟、事件丢失和历史数据导出。实测结果应该写进项目文档，而不是只保留在某个人的浏览器书签里。

几类常见误区

“永久免费”不等于“额度无限”。README 中列出的 Cloudflare、Deno Deploy、Sentry、OpenObserve、CircleCI、Netlify、Vercel 等条目，具体额度和条件都由各自供应商控制。免费额度可能按天、月、项目、组织或区域计算，也可能排除某些高级功能。云厂商的免费资源还可能要求绑定支付方式，甚至只在特定地区提供。

“开源”也不等于“托管服务免费”。free-for.dev 主要列出服务商提供的免费层，不能把服务商的商业承诺和对应项目的开源许可混为一谈。更不能因为某项服务可免费使用，就把生产数据、用户邮件或密钥直接放进去。

另一个误区是按每月可省多少钱来估值。免费层真正节省的是早期试错成本；一旦项目进入稳定业务，迁移风险、合规审查、可观测性缺口和供应商锁定可能远大于账单差额。

一套更稳的落地顺序

个人项目可以先从静态托管、DNS、代码仓库和基础监控开始，再逐项增加数据库、对象存储和第三方 API。每增加一项托管服务，都保留一个替代方案：静态站保留本地构建产物，数据库定期导出，日志保留关键事件的本地副本，密钥由独立的环境变量或密钥管理器托管。

团队项目则应该把免费层当成容量预算，而不是默认生产架构。为请求、构建、日志和存储设置接近免费额度但低于上限的告警；在 CI 中记录构建分钟和缓存命中；在 API 网关记录供应商、模型、区域和响应时间；对自动升级到付费计划的服务关闭不必要的 billing 权限。这样即使规则变化，也能快速发现。

值得长期保留的使用方式

这份清单最适合做三件事：启动项目时发现候选基础设施，定期复查已有服务是否仍然符合预算，以及在替换供应商时建立迁移备选。它不适合直接当采购清单，更不适合把文章中的一行额度复制到生产配置。

发布前应回到 free-for.dev 仓库 和各服务官方定价页核对当前条件。把核验日期、区域、账号类型和测试结果一起记录，远比收藏一张“白嫖服务地图”更有价值。