11月7日下午，DeepSeek 网页和 API 又出现部分中断。官方状态页记录，故障从北京时间15:11开始，对话、搜索，以及 V4 Pro 和 V4.1 Flash 两个 API 都受影响，15:56 被标为已解决。 四天前的11月3日，它刚从16:58崩到18:48，近两个小时。DeepSeek Status知乎
对刷两句问答的人，这是等一会儿；对拿它赶论文、赶代码、跑 Agent 任务的人，这45分钟可能刚好卡在交付前。更麻烦的是，宕机时的报错不总是“服务器繁忙”。有用户看到的是 `DeepSeek Messages stream ended before message_stop`，看起来像自己的插件或网络出了问题。 有人真去一个插件一个插件地试，试到一半才发现，崩的不是自己的电脑，是 DeepSeek。小红书知乎
所以第一件事不是换模型，也不是重装插件，而是先确认问题出在哪一边。打开官方状态页 status.deepseek.com，看它列出的受影响组件和恢复时间；不写代码的人，看这一层就够了。状态页还能订阅邮件提醒，故障开始、更新和恢复都会发通知。API 用户再看返回码：429 是请求速率或并发限制，500 是服务器错误，503 是服务过载。 同样是“用不了”，原因不同，处理方式也不同。知乎
确认是服务端的问题后，先救进度。把提示词、材料清单、已经生成的部分、下一步要做什么，复制到一个本地文档里。 换工具时，至少不用从头解释。对 Agent 任务，还要多一步：超时不等于没执行。发邮件、建订单、写文件这类动作，先确认上一次有没有真的完成，再决定重跑哪一步。 否则“接着做”很容易变成“重做一遍”，甚至重复执行。小红书知乎
如果等不了，就换一个试过的入口。备用模型不能只是另一个名字。最好拿一条真实的小任务试过：它能不能读懂同样的材料，遵守同样的格式，输出是否还能用。 临时在社交平台找的“满血版”也要留个心眼：第三方软件内置的模型可能是蒸馏或量化版，模型名里带 Distill、7B、8B 这类标记的，就不是满血。知乎小红书
一个具体的例子：英伟达 NIM 上的 DeepSeek-V4.1-Flash 可以免费调用，兼容 OpenAI 格式，能接进 DeepSeek Harness（DSH）、Codex 这类客户端。但它不是无成本的：有人实测，一个小任务从发送到完成用了4分22秒，大部分时间花在排队上。 它能救急，不一定能救“十分钟后就要交”。知乎
如果找不到可靠替代，就把不依赖 AI 的部分往前推：整理资料、列提纲、跑测试、核对引用。这比反复刷新更能保住进度。
服务恢复后，也别一键重跑。先看哪些步骤已经完成，只补失败的那一段；API 用户留好用量记录。10月15日那次，官方按10月8日到14日的消耗金额全额返还赠金，自动到账。 这次截至11月7日晚，状态页给出的仍是“已解决、服务已恢复”，没有补偿说明。21世纪经济报道DeepSeek Status
DeepSeek 可以再崩。赶工的人保不住它的服务器，但能保住自己的进度：崩的时候知道先看哪儿，走的时候带得走上下文，换工具时不用从头解释。下一次它再崩，希望你只需要换个入口，不需要重做一遍。
