12.4 万 Star 的 free-for-dev，一个只靠 Markdown 撑起来的「白嫖百科」

先说一个可能反直觉的事实。

GitHub 上 Star 数最多的项目里，有一大批根本没有代码。Linux kernel、TensorFlow 这种硬核工程当然在榜，但紧挨着它们的，是一堆看起来「什么都没做」的仓库，awesome-list、roadmap、cheatsheet、免费资源合集。

free-for-dev 就是这类项目里活得最久、最成功的一个。

截止 2026 年 6 月 28 日，ripienaar/free-for-dev 在 GitHub 上有 12.4 万 Star，1.3 万 Fork。它的全部内容，就是一个长达 23 万字符的 README.md。没有 src 目录，没有 package.json，没有任何可执行的东西。

就这么一个纯文本文件，攒了 12 万 Star，活了整整 11 年。

你想想看，这事儿本身就很值得琢磨。

它解决的问题，比你想的更具体

很多人会觉得，不就是个免费资源清单嘛，谁不会整理。

但 free-for-dev 真正值钱的，是它的边界卡得特别死。

README 一开头就把规则讲清楚了。这个列表只收录 as-a-Service 的免费层（free tier），不收录自托管软件。而且免费层必须满足，要么永久免费，要么时间桶化的至少免费一年。还有一条很关键，安全视角,如果某个服务把 TLS 加密锁在付费层才开放，作者直接拒收。

这几条规则把列表的质量一下就撑起来了。

因为它过滤掉了两种最常见的噪音。一种是「免费试用 14 天」这种营销噱头，试用完了就收费，对开发者没意义。另一种是「基础功能免费，HTTPS 要加钱」这种暗坑，对小项目是致命的。

剩下的，全是真能白嫖、能长期跑、能放心用的东西。这就是它的护城河。

所以它不是「什么免费资源都收」，它是「一个有品味的人，替你把 SaaS 免费层筛了一遍」。这种筛选的价值，在信息过载的年代只增不减。

它的目录，几乎覆盖了一个项目的完整生命周期

我建议你别从头读，23 万字符会看瞎眼。把它当字典查，需要哪块翻哪块。

它的分类细到什么程度，我把主要板块列一下你就懂了。

云厂商的永久免费额度这一章是镇店之宝。AWS、GCP、Azure 三大厂的免费层，精确到每个月多少次调用、多少 GB 流量、多少小时计算时间。比如 GCP 的 Cloud Run 每月 200 万次请求、36 万 GB-秒内存，AWS Lambda 每月 100 万次调用，Azure Functions 每月 100 万次请求，这些数字都是真金白银。

你做个人项目或者创业 MVP 的时候，光这一章就能帮你省下几百块服务器钱。

后面还有 CI/CD（GitHub Actions、GitLab CI 都在列）、托管和 PaaS（Cloudflare Pages、Vercel、Netlify 的免费额度对比）、数据库（Supabase、PlanetScale、Neon 这些托管 DB 的免费档）、监控、日志、DNS、域名、CDN、邮件、认证，甚至还有 生成式 AI（各家模型 API 的免费额度）。

说真的，一个现代 Web 项目从开发到上线要碰的所有基础设施，它都给你备好了免费选项。

我个人最常用的是 Tunneling 那一节。本地开发要做 webhook 调试，cloudflared、ngrok、localtunnel 这些内网穿透工具的免费方案，一目了然，省得我每次都去搜。

一个纯文本项目，凭什么活 11 年

这个问题我想了挺久。

因为 awesome-list 这种项目，死亡率其实很高。很多人一时兴起建一个列表，维护半年就荒废了，链接失效、服务关停、免费政策变更，没人跟，列表就成了信息垃圾场。

free-for-dev 活下来的关键，是它把维护这件事，做成了一个可持续的社区协作。

README 里写了一句很朴实的话，这份列表来自 1600 多人的 Pull Request、Review、想法和劳动。

它不是一个人在扛，而是一个社区在持续喂。有人发现新的免费服务就提 PR，有人发现某个服务改了政策就提 issue，作者 ripienaar 做的是「有品味的守门人」角色，把控标准、决定收不收。这个分工让项目既保持了质量，又不依赖单一个人的精力。

还有个细节我注意到了，它还有一个配套网站 free-for.dev，把这份 Markdown 渲染成了可搜索的网页版。这种「内容源在 GitHub，多端分发」的模式，让它的触达面远超一个纯仓库。

其实这背后是一个被低估的产品形态，curation as a product（策展即产品）。在 AI 能一键生成一切的时代，有判断力的筛选和持续维护，反而成了稀缺品。这个仓库 12 万 Star，说到底是全球开发者用脚投票，给「有人替我把好东西挑出来」这件事投的钱。

几个使用上必须知道的坑

聊到这我也得泼点冷水，这个列表虽然强，但它有几个天然的局限。

第一，信息会过时。云厂商的免费政策变得比天气还快，某个今天还免费的额度，明天可能就砍了。这个列表再勤快，也追不上所有变更。所以你拿它当起点找方向没问题，但真正上线前，一定要去官方文档核对当下的数字。别问我怎么知道的，踩过。

第二，免费层是有天花板的。免费 tier 设计的目的，是让你低成本试用、把项目跑起来，不是让你永久白嫖生产负载。流量一上来，超额费用可能比直接付费还贵。所以免费层最适合个人项目、demo、学习、MVP 阶段，一旦有真实用户，就该认真算账迁到付费。

第三，「免费」有时候是用数据换的。很多免费监控、免费分析服务，其实是拿你的使用数据做训练或营销。对个人项目无所谓，对有合规要求的企业项目，免费反而可能是最贵的。

第四，这个列表有明确的价值取向,它只服务 infra/devops 这群人。它 README 里直说了，不收那些离题太远的免费服务，哪怕很流行。所以你想找设计素材、找电子书、找影视资源，别来这，这不是它的地盘。

策展即产品，11 年挑出来的信任

我反复看 free-for-dev 这个项目，越看越觉得它点破了一个被低估的产品形态，前面正文提过的 curation as a product（策展即产品）。

它用 11 年时间，攒了一份清单，告诉所有开发者一个简单的道理，在你花钱买任何基础设施之前，先看看有没有人已经替你付过钱了。

这件事的价值不在于省钱本身。而在于它降低了创造的成本。

这里值得提炼一个可迁移的判断，当信息获取的边际成本趋近于零时，最稀缺的资产变成了「持续筛选的注意力」。AI 让生成变得廉价，反而让筛选变得更值钱，因为噪音和信号的差距被拉大了。free-for-dev 值 12 万 Star，不是给那个 Markdown 文件的，是给「有人 11 年如一日地把好东西挑出来、把过期的剔掉」这件持续的策展劳动。这个判断放到任何内容赛道都成立，未来最值钱的不一定是能产出最多内容的人，而是能持续帮别人省掉筛选成本的人。

一个学生、一个独立开发者、一个想试水副业的打工人，因为这份清单，可以零成本把一个想法跑起来。也许这个想法跑成了一个产品，也许跑成了一家小公司，也许最后什么都没成，但「试错成本被压到接近零」这件事，本身就改变了谁能参与创造。

因为真正稀缺的，从来不是信息，而是有人替你把好东西挑出来，还一直挑了下去。