“又挂两个现在还能白嫖的就这 18 个”。说实话看到这类标题点进来的人多半不是想看一份名单本身而是想确认两件事我一直在用的东西会不会突然没了以及我还漏了哪个可以捡便宜的地方。我自己维护免费资源清单超过五年期间见证过无数次“名单今天还是 20 个明天就只剩 18 个”的场面。说句不好听的这类标题里的数字越小越能勾人但数字本身就是会变的今天写 18下个月可能就成了 16 或者 14。真正值得聊的不是这 18 个具体是谁而是为什么它们会挂、怎么在挂掉之前发现信号以及怎样让自己始终保持一份稳定好用的“替代清单”。这篇文章不打算给你发一份只读一遍就会过期的截图式整理而是把我在长期维护免费资源过程中验证过的一套方法拿出来——包括选品标准、存活概率判断、监控脚本、降级预案。看完之后你完全能自己判断某个免费服务值不值得投入精力也能在又一批“挂掉”的坏消息传来时从容地把手上的资源切换到下一个。1. 免费服务“挂掉”不是意外而是免费模式必然的财务逻辑1.1 免费额度首先是获客成本不是永久福利理解任何免费资源之前先要搞清楚服务商为什么会给你免费额度。绝大多数情况下免费额度在财务上只有一个身份获客成本。一家公司拨一部分预算出来让新用户零门槛体验产品用的就是营销费用的逻辑。所以你会发现越是刚上线、越急需增长的服务给的免费额度越慷慨而一旦业务进入成熟期或者资本市场的考核从“用户增长”切换到“收入利润”免费套餐就会成为第一个被开刀的对象。这件事我见过太多次。某些云服务刚出来时新用户能拿到配置相当不错的免费实例建站、跑脚本、挂 Bot 全都够用。当时社区里一片叫好有人甚至鼓捣出一个“免费搭整套服务”的教程。可几个月后规则一变要么免费实例被替换成低配型号要么直接要求绑定支付方式才能继续用。本质原因很简单无门槛的免费资源被薅得太狠真实成本超过了市场预算产品经理再不砍额度年终报表就没法交代。认清这个逻辑你就不会再对任何一个免费服务产生“永远稳定”的幻想。你使用的是一个商业策略窗口期而不是一份终身契约。1.2 基础设施型免费额度比产品型免费额度活得久这是我总结出的第一条差异化判断同样是免费不同类型服务商的“挂掉”概率完全不同。一般来说基础设施型免费额度比产品型免费额度耐用得多。什么叫基础设施型对象存储、静态托管、Serverless 函数、开源模型推理、代码仓库、CI/CD 分钟数这些服务往往已经跑通了自己的商业模式免费额度只是整个产品体系中的一层体验入口背后有大量付费企业用户撑着。它们对免费用户的态度是“养着就行”不会太激进地收紧。产品型免费额度则危险得多。比如某个套壳 AI 应用、某个纯粹靠烧钱补贴的在线工具如果它本身没有清晰的企业付费路径和盈利模型一旦融资跟不上免费服务说关就关甚至整家公司都会消失。你可以去翻一翻过去几年倒掉的一批产品型工具很多人的“白嫖清单”就是这么一批一批长出来的也是一批一批葬送掉的。所以维护清单的第一条原则优先选基础设施少碰纯补贴产品。同样的时间精力投给一家已经活过五年的老牌云厂商远比投给一个爆火三个月的新产品靠谱。1.3 “挂掉”的三种典型方式根据我观察到的实际案例免费资源“挂掉”不是只有一种方式而是主要分三种判断和处理方式都不一样。关停式产品或功能被整体下线公告一出所有人都在找替代品。这种情况最干脆但也最伤因为你正在用的东西可能一夜之间就没了。降配式服务还在免费额度却从“够用”变成“不够用”比如并发数从 10 降到 3存储从 5GB 降到 1GB或者 GPU 运行时长被压缩到几乎无法完成一次训练。风控式技术层面没变但门槛提高了比如新用户必须绑定银行卡、必须完成企业认证、必须连续登录超过 30 天才解锁完整额度。对于想“零成本”使用的人来说这基本等同于被挂掉了。三种方式之间还有交叉。有些服务表面上没关停但你需要付出非常大的时间成本才能拿到那点免费额度本质上已经不值得了。以后看到“又挂两个”的新闻不妨先问一句是哪种挂法不同挂法对应的应对策略天差地别。2. 挂掉之前都有信号我的“免费资源体检清单”2.1 前置信号比正式公告更值得关注每一份免费服务在彻底关停之前一般都不会完全不打招呼。问题在于你平时不会盯着它的公告页看。我实践下来真正有效的信息来源有这么几个按灵敏度排序服务商官方公告和状态页最权威但有延迟通常等你看到的时候社区已经炸了。开发者社区和即时通讯群最灵敏。Reddit、V2EX、Hacker News以及各种垂直技术社群只要免费额度一有风吹草动几分钟内就有人发帖。这里的信息往往比官方公告早半天到一天足够你先做准备。更新日志和定价页变化很多服务商不会主动发公告而是悄悄修改定价页面。我的经验是给自己关心的每个服务建立一个定价页的监控标签隔几天点开看一次或者用脚本自动比对页面内容。口碑风向突变如果你发现一个原本被夸“良心”的服务最近开始频繁出现“限得厉害”“客服不理人”“退了退了”等评论那基本就是免费额度正在收紧的前兆。不要觉得只有关停才是问题。实际上降配和风控才是更常见的“挂掉”。官方不会专门发一封邮件告诉你“我们的免费额度降了”你只有实际用的时候才会察觉。所以我每个月都会花一点时间把我清单里的核心服务重新试一遍。2.2 一个轻量级自动化监控方案靠肉眼盯着十几个官网不现实我写了一个很小的 Python 脚本挂在服务器或者本机的系统计划任务里每天早上跑一次检查我维护的免费资源列表里每个服务的可用性。脚本思路很简单维护一个 JSON 文件里面记录服务的名称、检测 URL、期望返回的状态码和关键词。然后依次请求这些 URL如果状态码异常或关键词缺失就触发一次通知。下面是我实际使用的简化版本你可以直接复制改改就能用。import json import requests import smtplib from email.mime.text import MIMEText # 检测配置name服务名称url检测地址keyword用于判断页面是否正常的特征关键词 CHECK_LIST [ {name: Cloudflare Workers, url: https://workers.cloudflare.com/, keyword: Serverless}, {name: GitHub Actions, url: https://github.com/features/actions, keyword: Automate}, {name: Netlify, url: https://www.netlify.com/, keyword: Deploy}, ] def check(name, url, keyword): try: resp requests.get(url, timeout15, headers{User-Agent: free-resource-monitor}) body resp.text # 状态码异常或页面关键字消失都认为发生了“变化” if resp.status_code ! 200 or keyword not in body: return name, f状态码{resp.status_code}, 关键字缺失或页面结构变化 except Exception as e: return name, f请求异常: {e} return None def send_alert(messages): # 实际使用时换成你自己的通知渠道Server酱、邮件、Telegram Bot 均可 pass alerts [] for item in CHECK_LIST: result check(**item) if result: alerts.append(result) if alerts: print(以下免费服务状态出现变化, alerts) send_alert(alerts)这个脚本的定位不是侦查服务商的内部调整而是做“变动感知”。很多服务在关停或者改版之前都会先调整页面内容比如把“Free”改成“Free trial”把原来的免费文案换成“联系销售”这些都会导致关键词匹配失败从而触发警报。实际使用的时候你可以在 JSON 里维护几十个服务也不用担心每天请求量过大完全在合理范围内。2.3 配额验证要“实操”而不是“看文档”HTTP 可达并不能代表免费额度还能正常用。很多服务商的门槛不在“能不能访问”而在“能不能真正免费完成一个任务”。所以我每个月还会抽出半小时做一次“配额实操测试”用自己的账号实际跑一个最小化的任务比如调用一次 API、部署一个静态页面、创建一个数据库表然后观察消耗曲线是否和文档描述一致。这一步能帮你发现很多文档里没写的问题宣称每天 1000 次免费请求实际上新用户前三天就被限到 100 次宣称免费存储 5GB实际上需要在控制台手动申请而且审核周期长达两周宣称免费 GPU 可用实际排队两小时才能跑一次小任务且模型大小受限严重。凡是这类“名义上免费、实际很难用”的服务我会直接把它从清单里降级。白嫖的意义在于节省成本而不是支付隐性的时间成本。如果一个免费服务需要你反复研究规则、手动申请、应付各种审核那它已经不算免费了你付出的时间和精力就是另一种形式的“付费”。2.4 我维护清单时用的优先级标记资源多了之后光靠记性肯定不行。我会给清单里的每一项打上标签分成三个优先级S 级基础设施型、公司盈利稳定、免费额度基本够用。这类资源一旦用上可以深度依赖甚至可以围绕它搭建自己的项目。A 级免费额度不错但存在一定变数或者风控较严。这类资源适合做备选不建议把核心数据放进去。B 级短期赠送、需要绑卡、或者限制极多。这类资源顺手薅一薅可以但别投入太多精力。这个分级可以靠直觉也可以靠打分表后面我会详细说标准。总之你维护的不是一份名单而是一个动态的“资源配置表”。名单只是表头真正的价值在于你能随时判断哪些资源值得加大投入哪些需要尽快迁移。3. 比 18 个名单更重要的是 10 个稳定类目3.1 一份“白嫖资源”值不值得进入清单看这六个维度很多人看到别人发“这 18 个还能白嫖”就直接照着原样抄走也不管这些资源适不适合自己。这种抄作业的方式很容易翻车因为一份清单的成立是有前提的它基于维护者的网络环境、技术栈、业务场景和风险偏好。脱离这些前提谈“18 个”毫无意义。我更推荐用一套统一的维度去打分按自己的情况筛出专属清单。六个维度分别是维度说明打分量级免费额度实际可用额度是否满足具体任务1-5存活预期服务商盈利模式和生命周期1-5易用程度是否上手快、文档全、示例多1-5风控门槛是否需要绑卡、实名、审核1-5替换成本数据能否导出、迁移难度1-5社区活跃度遇到问题时能否快速找到答案1-5我在打分时会把“存活预期”这个维度加权到最高。一个免费额度再香的服务如果随时可能消失那它带来的稳定性收益就是负的。反过来一个产品用了五年还在哪怕额度一般也值得放进 S 级因为它已经被时间验证过了。3.2 长期来看我建议重点关注的 10 个资源类目与其死记 18 个具体型号不如记住 10 个资源类目。在每个类目里优质服务的分布相对稳定即使某一家挂了你也可以迅速在同赛道里找到替代品。下面是我目前维持的框架并附上一些我用过且相对稳定的案例。类目一静态网站托管。代表服务有 Netlify、Vercel、Cloudflare Pages。这类服务的免费额度很稳定免费带宽和构建次数对个人项目完全够用。因为部署的是静态内容成本对服务商来说非常低所以它们是免费资源里寿命最长的一类。我的个人站点和文档站都部署在这类平台上五年里几乎没有被折腾过。类目二Serverless 函数与边缘计算。代表服务有 Cloudflare Workers、各类 Serverless 云函数。它们适合跑轻量后端任务比如定时任务、请求转发、数据处理。免费额度通常是每天多少万次请求对个人开发和原型验证来说非常宽裕。需要注意的是这类服务一旦业务量上来就会收费适合个人项目不适合做高并发生产环境。类目三在线代码与实验环境。代表服务有 Google Colab、Kaggle 免费 Notebook。它们是做机器学习小实验、数据分析的好帮手。免费 GPU 的时长通常有限但用于学习和小型验证完全可行。这类服务的缺点是要排队、有时段限制适合当辅助工具不适合当主力计算资源。类目四Git 仓库与代码托管。代表服务有 GitHub、GitLab。无限私有仓库已经是标配关键是它衍生出的免费功能很值钱比如 GitHub Pages、GitHub Actions、项目看板、Issue 跟踪。代码托管是“白嫖清单里最该优先建立”的一类因为它不仅免费而且已经成为全球开发者的事实标准倒闭风险极低。类目五持续集成与自动化。代表服务有 GitHub Actions、GitLab CI、Cloudflare Workers 的定时任务。免费额度按每月分钟数计算对个人开源项目已经相当充裕。更重要的是用 CI 能解放大量重复劳动比如自动跑测试、自动部署、自动发布。这类资源属于“用习惯了就回不去”的类型。类目六托管数据库。代表服务有 Supabase、MongoDB Atlas。免费档一般有固定的存储容量和请求额适合小型应用和原型项目。因为数据这种东西一旦放进去就可能产生迁移成本所以我在选择时会特别看重导出能力。凡是不能方便导出数据的数据库服务免费额度再大我也不太敢投入。类目七对象存储与图床。代表服务有 Cloudflare R2 和各类云厂商的对象存储免费额度。它们适合存放静态资源、备份文件、用户上传的图片。对象存储的优势是便宜、体积大、API 标准统一就算换服务商迁移工具的生态也很成熟替换成本可控。类目八邮件收发与自动化。代表服务有 Cloudflare Email Routing、Resend 的免费额度、各类开源邮件服务。个人项目如果需要收发邮件不需要自己搭邮件服务器用这类服务就能解决。免费额度对个人域名足够而且配置简单。类目九文档、知识库与协作工具。代表服务有 Notion 免费版、各类在线白板和开源 wiki 系统。个人维护知识库、写笔记、做项目管理完全可以用免费额度覆盖。这类的特点是稳定性高因为文档型产品主要靠企业付费赚钱免费版通常是引流入口不会砍得太狠。类目十设计、原型与素材处理。代表服务有 Figma 免费版、Canva 免费版、各种开源的图片压缩和格式转换工具。设计师或博主维护素材库、做原型、处理图片时这些工具能省下不少订阅费。它们的免费额度对轻度使用足够而且账号体系和素材管理也比较成熟。这 10 个类目覆盖了个人开发者 80% 以上的日常需求。你不需要在每一个类目里都选一个但至少应该在关键类目里保持两个以上的候选这样才称得上“健康配置”。3.3 为什么我不建议你只盯着“具体清单”具体服务名单有一个天然缺陷更新频率永远跟不上变化速度。你可能今天照着别人的“18 个”去注册了三个其中两个注册页已经显示“该套餐已停止新用户申请”。不是维护者骗你而是信息本来就具有时效性免费资源的时效性尤其强。另外具体名单里的服务往往和推荐者的利益绑定。有些人推荐某个免费服务是因为他自己就在做这个服务的代理、教程付费社群或者返佣链接。这类推荐不一定没有价值但你必须留个心眼先用上面那六条标准独立评估一遍再决定要不要花时间注册。与其把“18 个具体名单”当成宝贝不如把自己训练成“能自己选出 18 个的人”。前者是锦上添花后者才是真正不会贬值的技能。4. 一份靠谱的“白嫖”心态比榜单更耐放4.1 不要把所有关键任务绑在单一免费服务上我见过不少人把自己项目的数据库放在某个免费数据库上博客放在某个免费托管上定时任务放在某个免费函数上。平时没什么问题一旦其中任何一项“挂掉”整个项目都跟着瘫痪。这种单点依赖是免费资源使用中最大的风险。我自己的做法是为主力资源设计降级路径。比如我的博客静态文件托管在 A 平台那么我会在 B 平台维护一个镜像站点域名切换只需改一条记录我的数据库用免费档那么我会定期把数据导出到自己的本地归档同时保留一个迁移脚本确保任何时候都能换到另一个同类服务。这套做法看起来很笨但在“服务挂掉”的突发场景下能帮我节省大量救火时间。4.2 免费额度的边界之外不做账号和规则滥用关于“白嫖”我的原则是可以在规则允许的范围内把免费额度用满但不要去做恶意注册、多开小号、批量薅羊毛、规避风控这类事情。这个建议不是为了站在道德高地上说教而是从成本收益角度来看规则滥用几乎没有胜算。服务商的免费额度设计里已经预留了风控模型一旦被识别为滥用账号轻则限流重则封号连带把你之前积累的数据一起清掉。为了多一点免费额度赔上正常使用的稳定性这笔账怎么算都不划算。真正健康的“白嫖”是把免费服务当成产品体验和效率工具而不是当成无限供给的“提款机”。只要你不滥用很多服务商甚至愿意长期保留一份还算肥美的免费额度作为社区影响力的种子用户。4.3 数据本地化是最后的底气每个免费资源都有可能消失但你的数据不应跟着消失。我不管用哪家免费服务都会定期执行“数据归集”把数据库导出成通用格式、把静态站点源码备份到本地仓库、把配置文件和 API Key 存进加密的密码管理器里。这样做的目的很朴素——无论服务商后续怎么改规则我手里始终握着全量数据。换平台只是重新花一两个小时做配置不存在所谓“被绑架在某个平台上动弹不得”的情况。这份“可迁移”的安全感才是免费资源时代真正的自由。5. 我在实际维护中的一些个人体会说几个不一定写在标准方法里的经验吧。第一免费额度监测不需要太频繁。每天跑一次状态检查就够了千万不要做出“每小时看一次配额”的强迫症行为。免费资源本意是省事如果为了盯它反而耗掉大量精力那就本末倒置了。我自己的频率是自动监测每天一次手动实操测试每月一次大小变更评估每季度一次。第二服务商越安静反而越可能出大事。有些团队会把重大政策变动拖到最后一刻才公布因为它担心过早通知会影响续费和销售。所以当你发现一个服务商连续几个月没有任何产品新闻、客服反馈变慢、社区口碑下降时就要开始准备替代方案了别等公告。第三优先选择那些“免费额度会随公司成长而增加”的服务而不是“免费额度靠融资硬撑”的服务。怎么判断看它是否已经形成稳定的企业付费业务、是否有活跃的开源生态、是否在行业里活了多年。满足这些条件的服务商送你免费额度是为了让你入坑企业版目的是培育长期用户不是打一枪换一个地方。第四也是最重要的一点保持更新你自己的“18 个”。所谓“还能白嫖的就这 18 个”在所有人心里的版本都不一样。你只有持续验证、持续调整才能维护出一份最适合自己场景的清单。别人的名单看一眼是启发自己维出来的名单才是底气。免费资源的本质是一场动态博弈服务商在平衡成本与获客我们在平衡成本与风险。只要你能读懂“挂掉”的信号掌握一套稳定的筛选方法并为关键任务准备好降级路径那么无论外头的名单从 18 变成 8 还是从 8 变成 20你都走得从容。