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 月份已經兌現了三次。