ChatGPT 又崩了，这次是第三次了

7月25日，ChatGPT 又崩了。

这不是什么小范围的卡顿，而是网页版、API 接口、编程工具 Codex 全线瘫痪——免费用户和 Plus 付费会员全都没能幸免。故障持续了大约 40 分钟到 1 小时，全球 DownDetector 上的投诉量短时间暴涨。

这是 ChatGPT 本月第三次出问题了。

很多用户一开始以为是自己网络不行，反复重启、换浏览器、改 DNS，折腾半天才发现——不是你的问题，是 OpenAI 那边崩��。

事故的直接原因，说出来有点尴尬：一次例行的云数据库维护。维护过程中下线了部分备用节点，结果剩余服务器瞬间涌入超额流量，核心认证模块被彻底挤爆。

看看这个过程有多连锁：流量激增 / 系统自动重试机制放大负载 / 认证模块过载瘫痪 / 缓存层和登录模块之间的协同节点「临时失灵」。就像城市电网的核心调度闸突然跳了，后续请求全部卡住。

有技术专家分析说，这不太可能是简单的流量突发导致的——OpenAI 的请求量级一直相对平稳。问题更可能出在 Kubernetes 或负载均衡器在常规更新过程中出现了异常。

换句话说，不是用户变多了，是系统自己把自己搞崩了。

这件事放到 ChatGPT 7 月的整体表现来看，就更让人捏把汗了。7 月 23 日刚修复一个持续了近 24 小时的故障，刚两天又崩了。一个月内两次重大宕机，而且这次还是第三次——同一个月。

这也引出一个更深层的问题：AI 基础设施的韧性，到底够不够？

ChatGPT 已经不是个新奇玩具了。大批企业、律所、高校、开发者把日常工作深度绑定在上面。一旦崩了，不是「等等就好」——很多办公室的工作流直接停摆，被迫切回人工模式。

业界已经开始呼吁建立「1+N」的多模型备份机制：ChatGPT 崩了能切 Claude，Claude 崩了能切 Kimi，Kimi 崩了还有 DeepSeek。听起来麻烦，但这次故障说明，把所有鸡蛋放在一个 AI 篮子里��风险确实挺大的。

回到 OpenAI 自己这边。这次事故告诉我们，大模型竞赛已经不只是拼参数规模了，稳定性、高并发承载能力、运维体系——这些「背后的事」越来越成为核心竞争力。

对普通用户来说，该做的也很简单：关键对话和重要资料本地留个备份，手边备一两个替代模型。不是 OpenAI 不好，而是「再强的服务也会有不在线的时候」——这个判断，7 月份已经兑现了三次。