ChatGPT桌面版静默闪退排查：日志、缓存与硬件加速

桌面版客户端最让人抓狂的一种故障，不是报错弹窗，也不是卡死转圈，而是界面毫无征兆地消失——上一秒还在等回复，下一秒窗口就没了，任务栏图标跟着一起蒸发，连个"程序未响应"的提示都不给。我用 ChatGPT 桌面版处理日常的资料整理和代码片段改写，前后在 Windows、macOS 两台机器上都遇到过这种"静默退出"，最频繁的时候一天能崩三次。起初我以为是网络抖动或者账号问题，重装、换号、换网络折腾了一圈，全是无用功；后来老老实实去翻日志、看崩溃转储、逐个目录清理缓存、把硬件加速这一层拆开试，才把问题定位到具体的渲染进程和 GPU 后端上。这篇内容就是把那段时间的排查路径完整摊开：怎么在"没有任何报错"的情况下拿到证据、日志应该看哪几行、缓存按什么顺序清才不是白清、硬件加速关到什么程度合适、以及哪些情况根本不是你电脑的问题。适合被闪退折腾过但还没找到方向的人，也适合平时只是偶尔崩一下、想把稳定性再往上提一档的人。不需要你会写代码，但需要你愿意按步骤动手。

1. 先分清"闪退"的三种形态，否则排查方向从第一步就错了

很多人一上来就是重装，重装完发现还是崩，然后怀疑是自己的系统有问题。问题在于"闪退"这个词太笼统，它至少覆盖了三种完全不同的故障形态，而这三类的排查入口根本不一样。我自己最早就是把"启动时一闪就没"和"用久了自动退出"当成同一个问题处理，结果两套动作互相干扰，白白浪费了一个周末。所以动手之前，先花五分钟给故障分个类，比直接开干值钱得多。

1.1 启动即退、使用中闪退、唤醒后闪退

启动即退：双击图标，图标亮一下就熄，任务管理器里可能闪过一个进程然后消失。这类问题八成出在配置文件损坏、缓存目录里某个数据库文件锁死、或者上一次异常退出留下的实例锁没释放。它的特点是"每次都退"，非常好复现，也最好修——清理配置基本能解决。

使用中闪退：能正常登录、正常对话，用了十几分钟甚至一两个小时后突然消失。这类高度可疑的是内存增长、渲染进程崩溃、GPU 进程挂掉。我遇到的大多数属于这一档，特征是"用越久越容易崩"，重启客户端之后又能撑一段时间。它是本文的重点。

唤醒后闪退：笔记本合盖休眠，第二天打开盖子，客户端窗口变成白屏或者直接不见了。这类和显卡驱动的电源状态切换、显示器拓扑变化强相关（比如插拔了扩展坞和外接屏），本质还是硬件加速那一层的问题，但触发条件很特定，容易误判成"软件质量差"。

分类的标准很简单：记录崩溃发生的时刻和你当时正在做什么。连续记三天，规律自己就浮出来了。这一步不需要任何工具，一个手机备忘录就够。

1.2 进程模型：主进程、渲染进程、GPU 进程谁先死

这类桌面客户端基本都是基于 Chromium 的多进程架构包装出来的，你看到的那个窗口，其实只是几个进程协作的结果。理解这一点非常关键，因为不同进程崩溃，日志长相完全不同，修复手段也完全不同。

主进程负责窗口管理、更新、菜单这些；渲染进程负责把界面画出来、跑前端逻辑；GPU 进程负责把绘制指令翻译成显卡能执行的命令；另外还有若干工具进程处理存储、网络这类杂事。渲染进程崩了，你会看到白屏或者窗口消失；GPU 进程崩了，界面可能还在但变成一片黑或者花屏，然后客户端整体退出；主进程崩了，那就是最干脆的直接消失，连痕迹都不留。

打开任务管理器（Windows）或活动监视器（macOS），在客户端正常运行时看一眼进程列表，记住里面有哪些进程名。崩溃瞬间如果来得及截个图，就能立刻判断是哪个进程先消失的。这个观察习惯我建议养成——它能把后面翻日志的范围缩小一大半。

1.3 动手前先做现场保护（取证清单）

在开始任何清理和修改之前，先把现场固定下来。这一步最容易被跳过，等到你清完缓存发现问题还在、却再也拿不到原始日志时，就只能在原地打转了。我在第二次遇到这个问题时才开始做这件事，效率提升非常明显。

需要保存的东西不多：

• 崩溃时间点（精确到分钟），以及当时在做的事；
• 客户端的版本号和安装包来源（是官网下载还是应用商店分发，两者路径和权限不同）；
• 崩溃转储文件（后面章节会讲具体位置，看到就复制出来）；
• 崩溃前后系统有没有做过更新、装过新驱动；
• 当时的电源状态和外接设备情况。

注意：不要在出问题后立刻点"重装"或"修复"。重装会覆盖掉可执行文件和部分配置，但崩溃转储和日志往往还留着，只是你可能再也对不上时间线了。先取证，再动手，顺序不能反。

2. 日志与崩溃转储：把"没有报错"变成"有据可查"

桌面客户端"看起来没报错"，只是因为它把错误写进了文件，没弹给你看。这类基于 Chromium 的客户端有一套相当成熟的日志体系，只是默认级别比较保守。你要做的就是找到它、打开它、读懂它。我第一次翻到自己的崩溃日志时，才发现里面明明白白写着 GPU 上下文创建失败的记录，时间戳和崩溃时刻严丝合缝——那一刻的感受是，前面所有的瞎猜都是在浪费时间。

2.1 三个系统的日志落盘位置

下面这些路径用的是通配写法，把<AppName>换成你的客户端实际的目录名即可（在对应父目录里看一眼就知道叫什么）。不同版本可能略有出入，但大致结构稳定。

Windows 上如果日志目录是空的，说明客户端没有开启文件日志，需要看系统事件查看器。用 PowerShell 拉最近的应用程序错误是最快的：

Get-WinEvent -FilterHashtable @{ LogName='Application'; Id=1000; StartTime=(Get-Date).AddHours(-6) } | Select-Object TimeCreated, ProviderName, Message | Format-List

macOS 上可以直接用log show按进程名过滤，比翻控制台界面高效：

log show --last 30m --predicate 'process == "<AppName>"' --style compact | tail -n 200

Linux 上如果启用了systemd-coredump，coredumpctl list能看到崩溃记录，coredumpctl info <PID>可以看调用栈。

2.2 日志里值得盯死的几类关键字

日志动辄几千行，不可能逐行读。我整理了一份自己的"关键字速查表"，每次出问题先在日志里全文搜索这些片段，命中之后基本就能定方向。

重点说两个。第一个是ContextResult::kTransientFailure，这个词组我最开始在日志里见过好几次却完全没在意，因为它不伴随任何用户可见的错误。它出现意味着客户端在尝试建立一个图形上下文时失败了，而失败后它会退到软件渲染或者直接放弃——这就是很多"用着用着黑屏然后退出"的真实原因。第二个是退出码，Windows 上-1073741819（也就是0xC0000005）在客户端日志里出现，几乎必然和显卡驱动层或者内存访问有关，跟"软件逻辑 bug"关系不大，这时候你去反馈功能问题是没有意义的。

2.3 用时间戳把复现步骤和日志对齐

拿到日志之后，最重要的一步不是读它，而是对齐时间线。具体做法：打开日志后直接跳到崩溃发生的那一分钟，然后往前看 30 秒内发生了什么。你会看到一串有先后顺序的事件，比如"开始加载某资源 → GPU 上下文创建失败 → 渲染进程退出 → 主进程清理"。

我自己的习惯是建一个简单的对照表，一边写"我做了什么"，一边写"日志里发生了什么"：

14:02 点击打开一个含长表格的对话 14:02 日志: Resizing window to 1440x900 14:02 日志: ContextResult::kTransientFailure 14:03 日志: GPU process exited unexpectedly 14:03 窗口消失

这种对照做两三次，规律基本就出来了。我当时就是靠这个发现：只要窗口尺寸跨过一个特定值（从普通尺寸拖到接近全屏），GPU 上下文就会重建一次，而重建在我的驱动版本上会失败。而后面的所有"用久了会崩"，其实都是这个根因在不同时机被触发而已。

2.4 主动开日志：用启动参数把级别调高

如果默认日志不够用，可以手动启动客户端并打开详细日志。基于 Chromium 的客户端都认这几个参数：

# Windows（在快捷方式的目标后面追加，或命令行执行） "<安装路径>\<AppName>.exe" --enable-logging --v=1 --vmodule=*gpu*=2 # macOS open -a "<AppName>" --args --enable-logging --v=1 # Linux <AppName> --enable-logging --v=1

--v=1把日志级别调高，--vmodule=*gpu*=2专门把 GPU 相关模块提到更详细的级别。日志默认写到chrome_debug.log，位置和上面表格里的日志目录基本一致。跑一次复现，然后把这个文件复制出来保存——因为下次正常启动时它可能被覆盖。

提示：加参数启动只是为了诊断。定位到问题之后要记得去掉这些参数，长期带--v=1跑会让日志文件滚得很快，磁盘占用和一点点性能开销都是不必要的。

3. 缓存与配置残留：清理顺序错了等于白清

"清缓存"这个词被用得太随便了。绝大多数人做的所谓清缓存，是在设置里点一下"清除数据"，那只清了网页层的存储，跟你真正需要清的目录往往不是一回事。而且清缓存这件事有一个非常反直觉的地方：如果你从最狠的那一档开始清，你会丢失登录态和本地设置，却依然可能没解决问题，因为根因在更深的地方。正确的做法是分级的、从轻到重的。

3.1 缓存目录其实是一堆东西混住在一起

在这些客户端的用户数据目录里，杂七杂八放着一堆东西，作用完全不同，混在一起清会误伤：

• Cache、Code Cache：网络资源和编译后的脚本缓存，清了只是首次加载慢一点；
• GPUCache、ShaderCache：图形相关的着色器和管线缓存，这一块最容易因为驱动更新而失效、进而引发渲染问题；
• Local Storage、IndexedDB、Session Storage：你的本地设置、草稿、会话状态，清了可能要重新配置；
• Service Worker：后台脚本缓存，异常时会导致启动卡住；
• Cookies、Network：登录凭证，清了要重新登录；
• Preferences、Local State：窗口尺寸、开关状态等配置，损坏会导致启动崩溃；
• SingletonLock、SingletonCookie（Linux/macOS 常见）：实例锁，残留会导致"打不开第二个实例"或启动即退。

理解了这一层，你就明白为什么"清缓存"有时候反而把问题搞复杂——你清掉了Cookies和Local Storage，重新登录，看起来"好了"，但真正的GPUCache还在原处，过两天又崩。

3.2 从轻到重的四级清理法

我现在的习惯是严格执行四级顺序，每一级做完都跑一次复现，确认无效再进下一级。这样即使问题没解决，你也不会丢失不必要的数据。

执行前必须先完全退出客户端。这里有个坑：点了关闭按钮、甚至托盘图标右键退出之后，进程未必真的没了。Windows 上打开任务管理器搜一下进程名，macOS 上在活动监视器里搜，确认零残留再动手。

目录操作示例：

# macOS / Linux：先备份再删除 cd ~/Library/Application\ Support/<AppName>/ cp -R GPUCache GPUCache.bak.$(date +%s) 2>/dev/null rm -rf GPUCache ShaderCache

# Windows：同样先备份 $p = "$env:LOCALAPPDATA\<AppName>\User Data" Rename-Item "$p\GPUCache" "GPUCache.bak" -ErrorAction SilentlyContinue

L4 那一级我建议不要直接删，而是整个目录改名而不是删除。改名之后如果新目录能正常跑起来，说明确实是配置问题，你还有回头路；如果新目录一样崩，那就说明问题不在用户数据里，把旧目录改回来就行，损失为零。这个"改名代替删除"的习惯帮我省过好几次事。

3.3 清理之后怎么验证生效

很多人清完之后就凭感觉判断"好像好了"，然后过几天又崩，陷入循环。有效的验证要满足三条：

第一，目录确实被重建了。清掉之后第一次启动，对应的目录应该重新出现，而且是空的或只有少量文件。如果清理后目录还是原来那堆文件、时间戳没变，说明你清的路径不对，或者进程没真正退出。

第二，日志里的那条错误消失了。带着--enable-logging启动，跑一次原来的复现步骤，再去日志里搜同样的关键字。如果原来每次必现的ContextResult::kTransientFailure不再出现，这一级的清理就是有效的。

第三，给够观察窗口。我给自己定的标准是"连续三天正常使用不崩"才算过关。只跑五分钟就宣布修好，很容易被下一次崩溃打脸。

3.4 那些不该乱清的东西

有几个目录我建议无论如何都留着：Cookies、Network（登录态）、Local Storage（本地设置和草稿）、以及任何带Backup或Sync字样的目录。清掉它们不会让你的问题更容易解决，只会让你在排查过程中反复登录、反复配置，增加变量。

还有一种情况需要特别注意：如果你装了同步类工具（网盘自动同步、文件历史版本），用户数据目录被同步软件扫到，可能在客户端运行期间被占用或者被"回滚"到旧版本。我见过一次非常诡异的"清完缓存重启又恢复原样"，最后查出来是同步工具把缓存目录当成普通文件一起同步了，删掉的瞬间被同步回来。把用户数据目录加入同步工具的排除列表，是排查前顺手就该做的一件事。

注意：不要用第三方"清理大师"类工具去清这些目录。它们通常按"体积大小"和"最后修改时间"判断，很容易把你正在用的Preferences或者锁文件一并删掉，制造出新的、更难查的问题。

4. 硬件加速：闪退高发区的开关与取舍

如果日志里出现了 GPU 相关的字样，那这一节就是重点。硬件加速在桌面客户端里是个双刃剑：开着能让界面更流畅、滚动和动画更省电，但它把稳定性的一部分责任交给了显卡驱动，而驱动是整个系统里最不受你控制的一环。我在两台机器上都遇到过"关掉硬件加速之后彻底不崩"的情况，也遇到过"关掉之后界面变卡顿但能用"的情况。它不是万能药，但在排查链条里必须先被排除。

4.1 硬件加速为什么会把客户端搞崩

简单说，客户端本身不直接跟显卡打交道，它把绘制指令交给一个中间层（图形抽象层），这个中间层再把指令翻译成具体平台能懂的图形接口调用。这条链路上任何一环出问题，表现都是"客户端崩了"，但责任可能在驱动、在中间层的后端选择、在系统的电源管理策略。

典型的几种失败模式：

• 驱动版本比较新，中间层的某个后端还没适配好，建立上下文时失败，客户端退到软件渲染或者直接退出；
• 笔记本双显卡切换时，客户端被分配到集成显卡，但某些图形特性只在独显上支持，切换瞬间上下文丢失；
• 外接显示器或扩展坞插拔，显示器拓扑变化导致帧缓冲被重建，重建失败就崩；
• 休眠唤醒后驱动重载，之前建立的上下文全部失效，客户端没有正确处理这个事件。

这四种模式有个共同点：它们都跟"你正在做什么"强相关，跟"客户端版本新旧"关系不大。所以升级版本往往解决不了，关硬件加速反而立竿见影。

4.2 关掉、降级、换后端三种手段

优先级从高到低，我建议按这个顺序试：

第一优先：用界面里的开关。设置里通常有一项"使用硬件加速"之类的选项，关掉它重启客户端即可，这是最干净的方式，不涉及任何参数，也不会随版本升级失效。

第二优先：命令行参数关掉。如果界面里找不到，或者开关不生效：

# Windows "<安装路径>\<AppName>.exe" --disable-gpu # macOS open -a "<AppName>" --args --disable-gpu # Linux <AppName> --disable-gpu

--disable-gpu会让客户端完全放弃 GPU 渲染路径。副作用是界面滚动和动画会明显变肉，视频类内容也更吃 CPU。如果你只是偶尔崩，可以先用这个参数验证"是不是 GPU 的问题"，确认之后再考虑更精细的方案。

第三优先：换图形后端。如果能确认是后端适配问题，与其一刀切关掉，不如换成另一种后端：

--use-angle=d3d11 # 默认通常就是这个 --use-angle=gl # 换到 OpenGL 路径 --use-angle=warp # 软件光栅化，最保守 --use-angle=swiftshader # 纯软件实现，兼容性最好、性能最低

我自己的经验是：--use-angle=warp在很多"驱动较新但适配没跟上"的机器上是性价比最高的选择——它保留了系统的其他图形能力，只是把这个客户端的光栅化交给 CPU 模拟。界面流畅度会降一点，但远比--disable-gpu后的整体卡顿好受。

还有一个参数--disable-gpu-compositing，它只关掉合成加速，保留部分 GPU 能力，适合"只在窗口缩放、拖动时崩"的场景。这个参数比较温和，值得作为中间档试一试。

提示：这些参数在 macOS 上的效果差异比较大，因为平台图形栈不一样。在 macOS 上优先试界面开关，参数往往不如在 Windows 上管用。

4.3 独显/集显切换与驱动回退的坑

如果你的机器是双显卡笔记本，硬件加速这一层还有几个额外的坑。

强制指定高性能显卡。在系统显卡控制面板里，把这个客户端的可执行文件单独指定为"高性能"，避免它在集显和独显之间反复横跳。切换本身就会重建上下文，每次都有一点崩溃概率，而"固定在一张卡上"能消除这个变量。我自己就是这么解决的其中一台机器——崩溃从"一天三次"降到"一周零次"。

驱动回退而不是升级。遇到闪退，很多人的第一反应是"更新驱动"。但现实是，新驱动引入回归问题的概率并不低，尤其是那些面向最新游戏的版本。更靠谱的做法是：把驱动回退到上一个你确认稳定的版本，观察三天。回退前一定要用驱动彻底卸载工具清干净（普通卸载会留下配置文件，容易和新旧版本混在一起打架），再重装目标版本。

关掉显卡超频和厂商的"游戏优化"配置。出厂超频、一键加速这类设置会增加图形栈的不稳定性，而客户端是长时间运行的负载，跟游戏那种短时高负载的容忍度不一样。

外接设备和扩展坞。如果你每天都在插拔扩展坞，试着在插拔前后各观察一次。我遇到过一次非常隐蔽的情况：通过扩展坞上的 HDMI 口接显示器时，每次合盖唤醒都会崩；直接插笔记本本体的口就完全正常。问题不在客户端，在扩展坞的显示通道处理上，但表现就是客户端闪退。

4.4 关闭硬件加速之后必须接受的三件事

很多人关掉之后又忍不住打开，因为觉得界面"不够顺滑"。这里把代价说清楚，你再决定：

第一，滚动和长列表会变肉。尤其是对话很长的时候，滚动会有明显的颗粒感。第二，视频类内容更吃 CPU，风扇转速可能会上去，笔记本续航会降。第三，某些交互动画会掉帧，但不影响功能。

我的取舍标准很简单：稳定性优先于流畅度。一个每天崩三次的客户端，再流畅也没法用。等你把根因定位清楚（比如确认是某个驱动版本的问题），再考虑把硬件加速开回来，那时候你至少知道该盯着什么。

5. 一次完整排查走查：从"每天崩三次"到稳定运行

前面几节是方法论，这一节把一次真实的排查过程完整走一遍。我把自己的记录整理出来，重点在于呈现"怎么想"而不是"最后怎么修"——因为你的机器和我的机器不一样，结论大概率不同，但思路可以照搬。

5.1 症状与初始假设

症状：某台 Windows 笔记本，客户端版本是当时的最新版。表现为使用 30 到 90 分钟后窗口突然消失，任务栏图标一起消失，无任何提示。重启客户端后能正常用，但时间长了必崩。插电和不插电都崩，但插电时崩得更快（说明负载有关）。

初始假设（按我的经验排序）：

1. 内存泄漏导致进程被杀；
2. 渲染进程在特定内容上崩溃（比如含大量表格的长对话）；
3. GPU 进程因驱动问题挂掉；
4. 缓存或配置文件局部损坏。

第一轮取证：打开任务管理器，发现崩溃瞬间内存占用大约 1.2 GB，不算离谱，机器总内存 16 GB，排除第一项。日志里搜关键字，发现ContextResult::kTransientFailure在每次崩溃前都出现，且都伴随GPU process exited unexpectedly。倾向于第三项。

5.2 逐层排除的执行记录

步骤一：清 GPUCache（L1）。完全退出客户端，确认任务管理器零残留，把GPUCache改名备份，重启。结果：撑了大约 2 小时才崩，比原来久，但没解决。这个结果说明 GPU 缓存确实参与了，但不是唯一因素。

步骤二：关硬件加速（界面开关）。设置里关掉硬件加速，重启。结果：连续使用一整天没崩，界面明显变肉。这基本锁定了方向——问题在 GPU 渲染链路。

步骤三：恢复硬件加速，改用参数。想找回流畅度，于是把界面开关打开，改用--use-angle=warp启动。结果：用了两天，一次没崩，流畅度比完全关掉好一些。到这里问题算压制住了。

步骤四：追根因（驱动版本）。不甘心一直带着参数跑，于是查了一下当前驱动版本，发现是两周前更新的。用彻底卸载工具清干净，装回上一个稳定版本，去掉所有参数，恢复默认配置。结果：连续使用五天，其中包含多次休眠唤醒和扩展坞插拔，零崩溃。到这里才算真正解决。

整个过程的耗时分布挺有意思：前两步花了不到半小时，解决了 80% 的可用性问题；第四步花了一个半小时，解决的是"每次更新驱动都可能复发"的隐患。如果你时间有限，做完前三步就可以收工。

5.3 这次排查里最值钱的两个判断

第一个判断是**"崩得更快"这个信号**。插电时崩得快、不插电时崩得慢，说明它和性能/功耗状态有关，而不是纯粹的随机故障。这个信号直接把我从"内存泄漏"的假设里拉了出来。

第二个判断是清理 GPUCache 后"时间变长但没消失"。这个结果非常重要——如果清完完全没变化，说明缓存根本没参与；如果清完彻底好了，说明就是缓存问题。而"变长但没好"说明缓存是链条上的一环，但不是根因。这种中间结果最容易让人误判成"有效果了，继续清"，从而放弃追踪真正的根因。我当时强迫自己继续往下走，才有了后面的驱动回退。

提示：排查时把每一步的"前后对比"写下来，哪怕只有一行。人对"感觉好像好了一点"的记忆极不可靠，三天后你根本分不清是真好还是心理作用。

6. 让它长期不崩的几个习惯

修好一次不代表以后不崩。这类客户端的稳定性受上游版本、系统更新、驱动更新三重影响，任何一方变动都可能让老问题复发。我在吃过几次复发的亏之后，养成了几个成本很低但很有用的习惯，这部分算是把前面所有方法的"日常化"。

6.1 版本更新与回滚策略

不要第一时间更新。新版本发布后的头几天，稳定性风险最高，而你恰好是最需要它稳定工作的时候。我现在的做法是：看到更新提示先放一放，等一周左右，或者在另一台不重要的机器上先用几天。桌面客户端的更新通常是自动的，如果你需要控制时机，可以在设置里关掉自动更新，改成手动检查。

保留上一版的安装包。这一点很多人不做。把每次下载的安装包按版本号命名存一份，出问题时能几分钟内回退。回退之后注意一件事：降级可能遇到用户数据格式不兼容。大部分客户端做了向前兼容，但不敢保证。所以回退前把整个用户数据目录复制一份，是最稳妥的。

更新后主动做一次"压力测试"。更新完不要只是打开看一眼就完事。我的做法是：打开一个长对话，来回滚动几次，拖动窗口改变尺寸，最小化再恢复，如果有外接屏就插拔一次。这几分钟能把大部分"更新引入的渲染问题"提前暴露出来，比等到正式用时崩掉强。

6.2 启动参数与常驻配置的取舍

前面提到的那些参数（--disable-gpu、--use-angle=warp等）都是诊断工具，不应该是长期状态。长期带着参数跑有两个问题：一是你忘记了它的存在，将来换机器或重装时完全想不起来；二是参数对应的行为可能在版本升级后改变，反而制造新问题。

我自己的规矩是：任何临时参数，写在便签上贴在显示器边框（或者记在笔记里），并且写清楚"什么时候可以去掉"。比如"等驱动更新到某个版本后尝试去掉"。没有这个提醒，参数会一直挂着，直到某天你换电脑才发现自己一直在用降级配置。

如果你确实需要长期使用某个参数（比如老机器上必须关硬件加速），建议把它固化到启动方式里，而不是每次手动敲：

# Windows：改快捷方式的 Target，追加参数 # 右键快捷方式 → 属性 → 目标，在引号外追加： --use-angle=warp

macOS 上可以做一个小的启动脚本（.command文件），内容就是open -a "<AppName>" --args --use-angle=warp，放到桌面或者程序坞里替代原图标。这样既保留了参数，又不会每次都要开终端。

6.3 什么情况下该停止折腾

有一种情况必须承认：问题不在你这边。如果日志里明确显示是客户端自身某个模块在特定条件下崩溃，而你已经排除了缓存、驱动、硬件加速、外设所有变量，那剩下的就只能等版本修复。这时候继续折腾驱动和系统设置，收益极低，风险却不小（把系统搞出别的问题）。

判断标准我总结成三条，满足任意一条就停手：

第三条听起来像是"认输"，但实际上是最理性的选择。工具是为工作服务的，不是反过来。我曾经为了一个偶发崩溃花了整整两个晚上，事后回想，那两个晚上如果用来做正事，产出远超"修好一个客户端"的价值。

6.4 一份可以直接抄的日常检查清单

最后把日常维护的东西压缩成一张清单，出问题时按顺序过一遍，五分钟内能覆盖 80% 的常见原因：

1. 完全退出客户端，任务管理器确认零残留进程；
2. 看日志目录里最新的一份日志，搜GPU、crash、out of memory三个关键词；
3. 清GPUCache（改名备份，不直接删）；
4. 确认显卡驱动版本，回忆最近有没有更新过；
5. 回忆最近有没有装新的外设、扩展坞、显示器；
6. 关掉硬件加速试一次，确认问题是否消失；
7. 以上都无效，备份用户数据目录，尝试全新目录启动。

这套流程我在三台不同配置的机器上都跑过，其中两次在第三步就解决了，一次在第六步定位到方向，还有一次确认是版本问题、直接等更新。

我个人在实际操作中的体会是，闪退这类问题最怕的不是难，而是"急着动手"。先把故障分类、把日志留住、把每一步的前后对比记下来，看起来慢，实际上是最快的路径。我最早那次折腾了整整两天没结果，第二次按这套流程走，从开始到定位根因只用了不到一个下午。真正省时间的从来不是更狠的操作，而是更准的判断。