现在很多人 vibe coding 做网站,代码和配置几乎全交给 AI,大多数时候确实能用,可“能用”和“一直能用”之间还有一段距离。
练手的 demo 挂了也就挂了。网站一旦有了用户、开始收钱,某天早上突然宕机,用户不会关心背后是什么原因,只会觉得这个产品不靠谱。
“暴死”有三种可能:网站宕机;账单爆了;网站看似正常,但核心服务坏了。

下面我把自己踩过的坑和网上真实发生过的事故整理出来,每个讲清楚:会出什么事,为什么重要,常见解决方案。
文末还有一段 prompt,可以直接复制给 coding agent 来把网站查一遍。
一、网站背后的过期时间
网站像一辆车,背后压着一沓证件,行驶证、年检、保险,每张都有到期日,哪张过期车都上不了路。网站背后的这沓证件是这些:
- 域名
- HTTPS 证书,有了它浏览器才不会提示网站不安全
- 各种 API key 和登录凭证,你的网站靠它们调用别人的服务
- 绑在云服务上的信用卡
- 免费试用期和预充值额度,比如 OpenAI 的预付额度,买了一年后就作废
域名反而最不用担心,注册商会提前好几周发邮件提醒。证书放在 Vercel、Cloudflare 这类平台上的,平台会自动续,基本不用管;只有自己租服务器装证书的人要自己盯,而 Let’s Encrypt 从 2025 年 6 月起已经不发到期提醒邮件了。证书一旦过期,访客会看到浏览器整页的安全警告,几乎没人会点进去,等于网站打不开。
最容易出事的是各种 key 和凭证。它们有的会提醒,但提醒发到你注册时用的、早就不看的邮箱;有的干脆不提醒。
我自己就栽过一次。我有一条自动化流水线靠一个登录凭证运行,凭证寿命一个月。到期那天流水线停了,连着挂了四天我才发现。到期日精确到哪一天都是可以知道的,只是没有任何东西在看着它。
防这件事,按这个顺序来:
- 能自动续的,全部打开自动续。域名开自动续费,证书交给平台托管,云服务绑一张有效期长的卡。
- 能让机器查到期日的,交给监控工具去查。证书和域名的到期日都能自动读出来,开源的 Uptime Kuma 自己部署就能免费做到;UptimeRobot 这类现成服务,这个功能要付费。
- 剩下那些查不到到期日的 key,拿到的那一刻就记下来。
最简单的记法是一张表格加日历提醒:写清楚每个 key 用在哪、哪天拿到、哪天到期,在到期前 30 天和 7 天各设一个提醒。它不花钱,缺点是全靠自觉,哪天新加一个 key 忘了登记,它就等于不存在。
我自己是把所有 key 存进密钥管理工具 Bitwarden Secrets Manager,在每个 key 的备注里写上签发日期和有效期,再让一个小程序每天读一遍,快到期时给我发邮件。这对个人项目够用,但算不上大公司的做法,大公司一般让平台自动定期更换密钥,人根本不用记。
不管用哪种,记住一条:**能让机器查的,就别靠手抄。**手抄的日期迟早会和现实对不上。
二、额度用完:网站停,或者钱包爆炸
云服务的额度很像手机流量套餐。有的套餐流量用完就断网,有的用完了自动按量扣钱。
云服务也分这两种。用完就停的,网站报错,但账单不会涨;用完继续扣钱的,网站照常运行,账单跟着流量一直涨。新手选平台时几乎不看这一项,可它决定了出事的时候,你丢的是一天的生意,还是一大笔钱。

几个常用平台的情况:
- Cloudflare 的免费档用完就停,到 UTC 零点自动恢复。升级付费档以后没有花钱上限,只会发提醒邮件。
- Vercel 的免费档用完会被限制功能。Pro 档超出部分按量扣钱,默认只发通知,想超额自动停,要自己去后台打开暂停开关。
- Supabase 的免费档不会扣钱,超了先通知,再限制服务。Pro 档默认开着花费上限。
- OpenAI、Anthropic 这类 AI 接口大多是预充值。余额用完,网站上的 AI 功能当场失效;开了自动续充,钱就会一直扣下去。这两家都能在后台设消费上限。
扣钱的那一种出起事来是什么样子?2024 年 2 月,一个放在 Netlify 免费档上的静态网站,里面一个 MP3 文件被人刷了 190TB 的流量,账单约 10.4 万美元,事情在网上闹大以后,Netlify 的 CEO 出面免了单。2026 年 2 月,一家三人小公司的 Gemini API key 被盗,48 小时被刷了 82,314 美元,他们平时每月只花 180 美元左右,Google 拒绝减免。
用完就停也有代价,它把“账单被刷爆”换成了“网站被刷停”。突然爆火的时候也一样。2024 年,插画社区 Cara 一周之内用户暴涨,在 Vercel 上欠下约 9.6 万美元。如果当时设了上限,这笔账单不会有,但网站会在最火的那几天关门。
所以按阶段选。还没收入的个人项目,宁可停一天,优先选用完就停,付费档也把上限设上。已经有付费用户的产品,停机可能比账单更贵,那就设预算提醒,再设一个远高于平时用量、但你付得起的上限,同时做好防刷,第八节会讲。
具体要做的:
- 把项目用到的每个云服务和 API 列出来,逐个去官方定价页确认,额度用完是停还是扣
- 每个付费服务都设预算提醒,AI 接口额外设消费上限
烧钱的数据库:D1
Cloudflare 的数据库 D1 收费方式很特别:它不按你查了几次算钱,按查询翻过了多少行数据算钱,写入也按行算。
这像一个按翻页收费的图书馆。有目录,你直接翻到要找的那一页;没有目录,就得把整个图书馆从头翻一遍,每一页都算钱。数据库里的目录叫索引。AI 写的查询如果没用上索引,每查一次就把整张表翻一遍。

更要命的是重复写入。2026 年 1 月,独立开发者 Nathan Schram 平时每月在 Cloudflare 上只花 5 美元左右。他的程序里有两个 bug,让同一批数据被反复处理、反复写进数据库。主要的那个 bug 跑了四天才被发现,那个月一共写了约 48 亿行,账单约 4,600 到 4,900 美元。他申诉了 18 天,最后拿到一次性减免。这种运气你不能指望。
用 D1 的话:
- 让 AI 找出最常用的几条查询,确认它们用上了索引。只给常用的查询建,别每个字段都建,索引会让每次写入多算钱
- 别让程序在循环里一条一条地查,改成一次批量查
- 同一批数据处理两遍,结果应该和处理一遍一样,不能多插一份。定时任务尤其要注意
- 在 Cloudflare 后台给 D1 设用量提醒
三、数据库没人用会休眠
Supabase 的免费项目,如果连续 7 天没人碰数据库,会被自动暂停,暂停前会发邮件。数据还在,但网站连不上数据库,要你登录后台手动恢复。
这个坑专坑两种人:网站访问量很低的,和做好了先放着、过段时间才推广的。你什么都没改,某天打开网站,发现它坏了。
有两条路。一是写一个每天跑一次的定时任务,去查一下数据库,让它保持活跃。这个任务自己也会悄悄停掉,比如 GitHub Actions 的定时任务,公开仓库连续 60 天没有任何活动就会被自动关掉,所以最好配上第九节监控告警里讲的打卡。二是升级 Pro,每月 25 美元起,付费项目不会被暂停。已经在收钱的产品,直接选这条。
四、数据库备份
网站挂了,重新部署就回来了,像房子塌了还能照着图纸重建。数据丢了,就是图纸和家具一起烧了。
丢数据的方式五花八门,包括 AI 亲手删。2025 年 7 月,SaaStr 的创始人 Jason Lemkin 在 Replit 上用 AI 写代码,AI 无视他“不经允许不许改动”的指令,删掉了正式环境的数据库。
我自己也差点删过。迁移平台时,我判断一个邮件订阅服务“从来没上线过”,准备把它的数据库当空库删掉。后来翻了修改记录才发现,那个订阅表单上线过六周,库里有 40 个真实订阅者。而那台机器上,当时没有任何备份。
先搞清楚平台默认给了你什么。D1 自带时光回溯,默认开启,免费档能回到 7 天内任意一个时间点,付费档是 30 天。Supabase 免费档没有自动备份,Pro 档每天备份一次,保留 7 天。Neon 免费档能回到 6 小时以内。
然后补上属于你自己的那一份:
- 定期把数据自动导出一份,放到另一个平台。平台自带的备份和数据在同一个地方,账号被封、项目被删的时候会一起没
- 至少真的恢复一次,把备份导进一个新库,确认数据都在。没试过的备份,出事那天很可能用不了
- 删除任何数据库之前,先导出一份
五、AI 改一处坏一处
vibe coding 有个很常见的节奏:让 AI 加一个小功能,它顺手改了好几个文件,你测了一下新功能没问题,就上线了。几个小时后才发现,登录坏了,或者付款开通不了了。AI 改的范围经常比你以为的大,你测的范围经常比它改的小。
防这件事靠三样东西。

第一样是回滚,像玩游戏读档。Vercel 和 Cloudflare 都能在后台一键回到上一个版本。出事的第一反应是先回滚,让网站恢复,再慢慢查原因。有两点要知道:这个档只存了代码,数据库里的数据不会跟着回去,所以让 AI 改数据库结构之前,先备份;Vercel 回滚之后会暂停自动发布,修好以后要去后台手动恢复。
第二样是预览,像正式演出前的彩排。Vercel 和 Cloudflare Pages 会给每个分支生成一个预览地址,先在预览上点一遍,没问题再发布。要先确认预览连的是测试数据库和支付的测试模式,别在彩排的时候动了真钱和真数据。Cloudflare Workers 的预览默认用的就是正式数据,要格外小心。
第三样是测试。每次上线前,至少把注册登录、付款、核心功能这三样走一遍。更省事的是让 AI 写成自动测试,每次改完自动跑。不会写也没关系,Playwright 这个工具能把你在网页上的点击录下来,自动生成测试。Anthropic 在 Claude Code 的官方最佳实践里说过,给 AI 一个检查自己工作的办法,是你能做的最管用的一件事。有测试,AI 改坏了东西会自己发现;没有测试,它只会告诉你“改好了”。
最危险的故障,看起来一切正常
有一类故障不会报错,它只是让某个环节安静地失效。
我的邮件订阅服务就出过这种事。它需要一个发邮件服务的 key,可部署的时候这个 key 是空的。用户填完表单,页面显示订阅成功,数据也正常存进了数据库,只是欢迎邮件一封都没发出去,前后持续了大约六周。
付款是另一个重灾区。用户付完钱,Stripe 这类支付平台会主动给你的网站发一条付款通知,开通订单要靠这条通知。如果只靠付款后跳回来的那个页面开通,用户付完钱顺手关了页面,钱收了,订单却没开。
防这件事:
- 缺了关键配置(比如那个空的 key)时,让部署直接失败,别带病上线。这一条可以直接让 AI 加
- 程序出错要报出来,接上 Sentry 这类错误监控,别让错误被悄悄吞掉
- 付款流程让 AI 按 Stripe 官方要求查一遍:靠付款通知开通,确认通知是真的,同一条通知只处理一次
- 隔一段时间对一次账,看 Stripe 收到的钱和系统里开通的订单能不能对上
六、密钥管理
说到网站安全,很多人想到的是黑客专门盯上你。新手的网站更常碰到的,是自动化脚本在扫描整个互联网,专找没锁的门。安全公司 Escape.tech 在 2025 年 10 月扫描了 5,600 多个用 vibe coding 平台做的公开应用,找到 400 多个暴露在外的密钥,还有 175 处个人隐私数据泄露,其中包括医疗记录和银行账号。
API key 相当于你在某个服务商那里的银行卡加密码,谁拿到谁就能花你的额度。AI 为了让功能尽快能用,经常把 key 直接写进网页代码,而网页代码会原样发到每个访客的浏览器里,任何人打开开发者工具都能看到。Next.js 里名字以 NEXT_PUBLIC_ 开头、Vite 里以 VITE_ 开头的变量,都会被这样公开。
另一种情况,是把存着 key 的 .env 文件传到了公开的 GitHub 仓库。有研究者故意把 AWS 的 key 放进公开仓库做测试,1 分钟之内就被盗用了。
- 花钱的 key 只放在服务端,网页通过你自己的后端去调用
- 后端接口本身也要限制谁能用、用多快,不然别人不用偷 key,直接刷你的接口,烧的一样是你的钱
.env一开始就写进.gitignore,不让它被传上去- key 一旦公开过,哪怕只有几分钟,第一件事是去服务商后台作废它、重新生成一个。只删提交记录没用,它可能早被抓走了
至于 key 平时怎么存,记住这几条就够了:
- 存在部署平台自带的密钥设置里。Vercel 的环境变量记得勾选 Sensitive,Cloudflare 用 Secret 类型,存进去之后连后台都看不到原值
- 代码里只写 key 的名字,运行时再去读取,值本身不进代码,也不进聊天记录。别把 key 直接贴给 AI,让它帮你配好
- 开发用的 key 和正式网站用的 key 分开,能限制权限和额度的,只给够用的那一点。哪把泄露了,影响范围也小
- 项目多了、好几台机器要共用一批 key 的时候,再上专门的密钥管理工具,我自己用的是 Bitwarden Secrets Manager
从 key 散落在各处到统一管理,我自己踩了不少坑,以后会专门写一篇文章分享这段经验。
七、数据库门禁
用 Supabase 的人要特别注意一个叫 RLS 的设置。Supabase 允许网页直接读写数据库,用的是一把本来就公开的 key。真正决定谁能读写哪些数据的,是每张表上的门禁规则,也就是 RLS。没开门禁,任何人拿着那把公开的 key,都能读写你的整张表。
坑在这里:在 Supabase 后台点按钮建的表,默认开着门禁;写代码建的表默认不开,而 AI 帮你建表,几乎都是写代码。
研究者 Matt Palmer 扫描了 1,645 个用 AI 建站工具 Lovable 做的公开应用,发现其中 170 个的数据表任何人都能读写,泄露了用户的姓名、邮箱、手机号和付款记录。Lovable 的回应是,数据安全应该由每个应用的开发者自己负责。平台不会替你担这个责任。
防法很直接:每张表都开 RLS,然后打开 Supabase 后台的 Security Advisor,它会把没开门禁的表标出来。最后切换成未登录的身份试一下,确认读不到别人的数据。
八、接口限制
注册、发验证码、发邮件、调 AI 的接口,只要不加限制,就可能被脚本刷一整夜。刷 AI 接口,烧的是你的额度和钱。刷邮件更隐蔽:脚本用一堆假邮箱注册,你的网站挨个给这些地址发验证邮件,结果大量退信,邮件服务商会因此暂停你的发信(Resend 要求退信率低于 4%),正常用户也收不到邮件了。短信更贵,有一种诈骗专门让你的网站往高价号码狂发验证码,攻击者从中分成。
还有管理后台。很多人的 /admin 页面只是没在首页放链接,并没有真的要求登录,而扫描程序专门会去试这种常见地址。
- 注册、登录、发送类的表单接上人机验证,比如免费的 Cloudflare Turnstile,网站不在 Cloudflare 上也能用。记得让 AI 确认服务端也做了校验,只在网页上放个验证框等于没装
- 给接口限制频率,先用你所在平台自带的功能,Cloudflare 和 Vercel 的免费档都能设 1 条限流规则
- 发短信验证码的,只开你真正需要的国家和地区
- 管理后台必须真的要求登录
- 只给自己用的工具,干脆别放到公网上,放进内网,或者在门口加一道邮箱验证
至于 DDoS 这种大流量攻击,Cloudflare 所有套餐都带防护,免费档也有,Vercel 也会自动拦。真正要担心的,是自己租服务器、把服务器地址直接暴露在公网的情况,最简单的办法是把网站放到 Cloudflare 后面。
九、监控告警
前面八个问题各有各的防法,但总有漏的时候。监控告警,是为了在出事的第一时间知道它出事了。

首页能打开,不代表网站是好的
最基础的监控叫存活检查:一个外部服务每隔几分钟访问一次你的网站,打不开就通知你。它像量体温,能发现发高烧,可发现不了半死,也发现不了第五节里那种看着正常其实已经坏了的情况。首页能打开,不代表登录能用、数据库能连。
所以最好再让 AI 写一个健康检查接口,相当于定期体检,它会真的去数据库查一次,再确认关键配置都在。让 AI 写的时候交代清楚四点:只读不写;每一步都设超时;出了问题只回答“不正常”,不暴露内部细节;检查频率放低到 30 到 60 分钟一次,免得按读取量收费的数据库白白花钱。
告警要发到你真的会看的地方。只发邮件很容易被淹没,最好推到手机上。
告警太多,等于没有告警
这是我自己踩过的坑。我给服务器和网站配了 41 项检查,4 天里收到 22 封故障邮件,真正的故障一个都没有。后来真有一台机器重启了,那唯一一封真实的通知和十几封假警报躺在同一个收件箱里,差点被我当成噪音划掉。
假警报最大的危害,是让你不再相信告警。Google 讲网站运维的 SRE 手册里有一条原则:每一次告警,都应该是需要人去处理的。
- 网站好好的时候也会响的告警规则,就该改
- 偶尔失败一次先别报,连续失败或者从别的地点复核过再报,UptimeRobot 这类工具自带复核
- 宁可少监控几项,也要让每一封告警都值得点开
监控自己挂了,你也不会知道
监控程序自己挂了,它不会告诉你。你只会以为一切正常,因为没收到任何告警。
解决办法像值班打卡。让监控程序每次正常跑完,去一个外部服务打一次卡,超过约定时间没打卡,外部服务就给你发告警。备份脚本和定时任务也一样,跑完就打卡,哪天没打,就说明它悄悄停了。
背后的道理很朴素:负责报告故障的东西,不能和可能出故障的东西一起倒下。
十、免费工具推荐
给新手推荐它们是因为免费档够小网站用、允许商用、注册就能用,不用自己架服务器,并不代表它们是各自领域唯一的选择。
- UptimeRobot:网站打不开时通知你。免费档有 50 个监控,每 5 分钟检查一次,条款允许商用,还能推送到手机 App,不会淹没在邮箱里
- Sentry:网站代码出错时通知你,并告诉你错在哪。它是错误监控里最常用的工具,官方直接支持 Next.js 和 Cloudflare Workers,让 AI 接入很容易。免费档每月 5,000 个错误,一个人用够了
- healthchecks.io:给备份和定时任务打卡,哪天没打卡就通知你。数据库保活、自动备份、监控程序本身,有没有悄悄停掉,都靠它来发现。免费 20 个检查
另外,Cloudflare、Vercel、Supabase 和各家 AI 接口后台的用量提醒也是免费的,记得一起设上。
十一、出事之后,先止血再排查
真出事了,按这个顺序来:
- 先把相关的日志导出来存好。平台日志留得很短,回滚之后再去找可能就没了
- 回滚到上一个能用的版本,让网站先恢复
- 数据坏了的话,先把备份恢复到一个新库,核对没问题再切换过去,别直接覆盖原库
- 出事过程中就告诉受影响的用户,别等修好再说。UptimeRobot 的免费档带一个状态页,可以用来发通知
- 恢复之后复盘:怎么发生的,为什么没早点发现

把这段 prompt 交给 AI
把下面这段 prompt 复制给 Claude Code、Cursor 或者其他 AI 编程工具,让它把你的项目从头查一遍:
请帮我检查这个网站项目,找出可能让它突然打不开、账单暴涨,或者表面正常其实已经坏掉的问题。
规则:只检查,不修改任何文件;不要运行会写数据库、发邮件或花钱的命令;报告里出现密钥时只显示前 4 位。
重点看这几类:
1. 会过期的东西:域名、证书、API key、登录凭证,哪些会过期,有没有人记着到期日
2. 额度和账单:用到的每个云服务和 API,额度用完是停服务还是继续扣钱,有没有设上限;有没有特别费钱的数据库查询,或者可能反复写入同一批数据的逻辑
3. 数据库:免费数据库会不会因为闲置被暂停,有没有自动备份,备份放在哪
4. 代码和部署:登录、付款等核心功能有没有测试,出错时会不会悄悄失败,付款开通是不是靠支付平台的通知
5. 密钥:必须保密的密钥有没有暴露在网页代码或 git 历史里(本来就允许公开的 key 不算)
6. 数据库权限:每张表有没有权限控制,未登录的人能不能读到数据
7. 接口防刷:注册、发邮件、发短信、调 AI 的接口有没有频率限制和人机验证,管理后台有没有要求登录
8. 监控:网站挂了或出错时,我能不能第一时间知道
每个问题告诉我:在哪个文件、为什么危险、怎么修。代码里看不出来的(比如平台后台的设置),告诉我去哪里自己确认。最后按严重程度从高到低排序。
做了这些,网站也不会绝对安全,但下一次出事的时候,你会收到提醒,也知道该怎么抢救。
评论