ChatGPT 网页版 CPU 跑满、风扇狂转：原因排查与解决办法
ChatGPT 网页版近期出现 CPU 占用飙升、风扇狂转的情况，换浏览器依旧复现。本文整理现象特征与可能原因，包括超长会话渲染、后台标签页任务、流式输出动画等，给出用浏览器任务管理器定位问题的排查清单，以及清历史、拆会话、关标签页等可操作的缓解手段，并说明各做法的适用场景与取舍。
ChatGPT 网页版最近出现了一类资源占用异常：页面开着、只是挂在后台不操作，CPU 也会被吃满，笔记本风扇转速飙升、机身发烫、电池掉电加快。有人最初怀疑是 Chrome 插件太多，换成 Safari 或 Firefox 之后问题依旧；Windows、macOS、Linux 上都有类似反馈，手机端浏览器也出现了输入文字变慢的情况。
这不是个例，但也不是所有人都中招——同一时间有人用 Chrome 一切正常，占用只有个位数。这说明它更像是特定条件下的触发问题，而非全员故障。下面把讨论里出现的现象、猜测与可操作的排查方法整理一下。
现象：和浏览器关系不大，和「挂着」关系很大
归纳下来有几个共同特征：
- 换浏览器后不复现的情况很少，Chrome、Edge、Safari、Firefox 都有人报告。
- 使用过程中不一定卡，反而是切到别的标签页、把页面晾十几分钟再切回来，风扇开始起飞。
- 打开浏览器自带的任务管理器，该标签页的 CPU 占用可达几十甚至两百多（多进程累加）。
- 手机端也有表现，例如在 Firefox 里输入文字明显变慢。
- 有人全程正常，占用个位数，说明账号类型、使用强度、会话内容可能都参与其中。
可能的原因
1. 超长会话的渲染压力
被提及最多的一条是：对话条数越多越卡。有人观察到主 JS 线程被占满，怀疑是渲染问题而不是计算问题。一个会话里堆了上百条消息、大量代码块和 Markdown 时，每次重渲染、每次滚动都有成本，再叠加语法高亮、公式渲染，开销会进一步放大。
但也有人删空历史后依然卡，所以它只是一个诱因，不是唯一答案。
2. 后台标签页没有真正「休眠」
网页在后台仍需维持连接、轮询或保持长连接，某些实现里还会跑 Web Worker。如果这些任务没有被浏览器的节能机制冻结，就会出现「我没在用它，它却在算」的观感。这也解释了为什么刷新能缓解一段时间，之后又复发。
3. 流式输出、动画与合成层
逐字输出的打字机效果、光标闪烁，加上复杂的 DOM 结构，会让重绘与合成持续发生。对集成显卡或较老的机器，这部分开销往往比纯 CPU 计算更明显。
4. 扩展与硬件加速（次要因素）
扩展确实会放大问题，但既然换浏览器仍然复现，扩展最多算加重项。硬件加速开关、显卡驱动偶尔也有影响，但需要自己对比验证。
排查清单
按顺序做，每一步记录结果，才能定位到具体环节：
- 用浏览器自带任务管理器确认占用来源。Chrome / Edge 按
Shift + Esc；Firefox 打开about:processes；Safari 可在系统的活动监视器里看对应进程。重点区分是标签页进程还是 GPU 进程。 - 新开一个无痕窗口（默认不加载扩展）打开同一个会话，对比占用。
- 新建一个全新对话，只发一两句话，静置十分钟以上再看占用。这一步能区分「历史太长」和「页面本身有后台任务」。
- 关闭硬件加速再测一次，看曲线是否变化。
- 换一个浏览器交叉验证，注意保持同一台机器、同一网络。
- 记录升高时机：是刚打开就高，还是切到后台一段时间后升高。
可以尝试的缓解办法
| 做法 | 适用场景 | 代价 |
|---|---|---|
| 清空或归档超长会话，重要内容另存 | 单会话消息数很多、滚动卡顿 | 丢失上下文，需要重新贴背景 |
| 长任务拆成多个短会话 | 日常问答、写代码 | 需手动维护上下文 |
| 用完即关闭标签页，不长期挂着 | 后台占用升高的场景 | 下次要重新打开 |
| 定期刷新页面 | 刷新后能恢复的情况 | 正在生成的回答会中断 |
| 关掉不必要的扩展与主题脚本 | 装了较多扩展 | 功能减少 |
| 改用桌面客户端或 API | 需要长时间在线跑任务 | 需配置，可能按量计费 |
几点说明：
- 清理历史对「渲染型卡顿」有效，对「后台任务型占用」无效，这正好解释了为什么有人清完就好、有人清完还卡。判断方法是看清单第 3 步的结果。
- 刷新只是重置状态，不解决根因，适合当临时手段。
- 如果只是不想在本地渲染超长回答，可以把内容复制到本地编辑器阅读，网页只保留提问。
关于「被拿去挖矿」的猜测
讨论里有人半开玩笑说网页在偷偷用用户的 CPU 干活、甚至挖矿。从可观察到的现象看，更合理的解释是前台渲染与后台任务叠加，而不是恶意利用。但这类猜测靠肉眼无法证伪，稳妥的做法是：
- 用浏览器任务管理器确认高占用确实来自该站点进程，而不是其他标签页或系统进程。
- 不在页面里粘贴密钥、口令等敏感信息，尤其在怀疑存在异常脚本时。
- 若占用异常且持续，可临时换其他入口（客户端、API）过渡，同时关注官方状态页与社区反馈的进展。
至于「故意做卡逼人付费」这类说法，目前没有任何证据支持，不适合当结论。
什么时候该换思路
如果本地设备本身性能吃紧——比如老款轻薄本、内存偏小，同时又要长时间挂着页面跑任务——把工作负载挪走是一个思路。除了关标签页、换客户端，也有人租用一台放在机房的 Mac mini，远程连接使用，本地只做显示，风扇和续航压力会小很多；这类方案适合「必须长时间在线」的场景，网络延迟与成本需要自己权衡，并非所有情况都值得。
另外，纯粹为了聊天就让一个重前端页面长期挂着，本身就不划算。能用 API 或命令行工具完成的任务，交给它们通常更省资源。
小结
- 现象真实存在，跨浏览器、跨系统，但不是所有人都能复现。
- 最可能的两个来源：超长会话的渲染开销，以及后台标签页没有真正停下来。
- 定位靠浏览器任务管理器、无痕窗口、空白会话三步对比，别凭感觉下判断。
- 缓解手段按「清历史 → 拆会话 → 关标签页 → 刷新」的顺序试，哪个有效就用哪个。
- 官方是否修复、何时修复，以官方发布的最新说明为准，不要轻信版本号传言。
