11月3日16:58，DeepSeek 的网页和 API 出现部分中断；17:06 起部分服务转为性能下降，17:13 短暂恢复，17:36 又降级，直到 18:48 才恢复。金融界统计，今年1月至今 DeepSeek 累计发生55次故障，状态页上最长的一次修了2天。当天官方公告说中断已修复，但 V4 Pro、V4.1 Flash 的 API 和对话服务仍存在性能下降。金融界财联社
把时间拉长看，这不是偶发。3月29日晚到30日上午，网页和 App 瘫痪约12小时，用户遇到登录失败、对话中断，还有内容丢失。10月15日那次，新浪科技直接写“年内至少第18次大面积异常”，把症结指向算力供需失衡。IT之家新浪科技
对靠它干活的人来说，合理的预期不是“永不宕机”，而是“经常降级、偶尔长时间断”。官方状态页上，很多条目写的是“性能下降”：变慢、超时、排队，并不等于彻底打不开。备份要接住的不只是“断”，还有“慢”。
多数“平替清单”备份的是入口。真正让人停工的，常常是上下文和成果只存在那个对话框里。有人发微博说，和 DeepSeek 聊了几个月的聊天记录没了。这不是说每次故障都会丢记录，而是提醒你：对话不是硬盘。微博
第一层备份，是把对话变成文件。每完成一段，把目标、约束、已确认的结论、下一步，连同当前产出，贴到本地笔记或项目文件。下次不管换哪个模型，开头把这份“交接单”丢进去。这一层不需要任何工具，今晚就能做。
第二层才是入口。网页和 App 用户至少要有一主一备一离线：主力之外，选一个不同厂商的备胎，再留一个本地或离线工具兜底。备胎要提前用真实任务跑过，知道它差在哪；收藏夹里的链接不算。也别把所有人往同一个备胎赶。11月3日有人转去小米 MiMo，排队2000多人。同一时间大家一起切换，备胎也会堵。微博
用 API 的人，别把 base_url 和 model 写死在业务代码里，做成配置或别名；换供应商时只改入口，不动业务逻辑。走 OpenAI 兼容网关的话，通常主要改 base_url、API Key 和模型名。但别以为完全无痛：鉴权、参数、限流、错误格式都可能有差异，切换后要用自己的真实 prompt 复测。给调用设超时和有限次重试，不要无限重试。知乎
第三层是自动切换的边界。网关可以在主模型失败时自动换一家，但换的不只是请求，还有请求里带着的数据。故障可以改变服务选择，不能自动扩大数据的可发送范围。合同、客户资料、没公开的代码，不能因为主模型超时就被悄悄发给另一家。更稳的顺序是：先按数据类别筛出允许的端点，再在允许的端点里比健康和速度；连接故障、限流、权限拒绝分开处理，权限拒绝不能靠换一家绕过。没有合适出口时，延后任务或转人工，比乱发出去强。知乎
今晚可以先做三件事：把正在做的活写成一份交接单；选一个不同厂商的备胎，用同一段真实任务跑一遍；把 API 的 base_url、model 和超时挪进配置。备份不是盼着 DeepSeek 出事，是它出事时，你不用跟着停工。
