禁用gpu加速必须通过启动参数--disable-gpu生效，因vscode的ui渲染链路在进程启动早期即由electron初始化gpu进程，settings.json加载时已错过时机；该参数跳过gpu进程创建，强制cpu软件光栅化，不影响核心功能。
禁用 GPU 加速能立刻缓解 VSCode 界面闪烁、花屏、黑块、拖拽撕裂等问题，但必须通过启动参数 --disable-gpu 生效，设置界面里关不掉它。
为什么 settings.json 里关不掉硬件加速
VSCode 的 window.enableGPUAcceleration 这类配置项在 2024 年后已被移除或失效；UI 渲染链路在进程启动早期就由 Electron（基于 Chromium）初始化 GPU 进程，等 settings.json 加载时早已错过时机。试图在 settings.json 里写 "window.webPreferences.enableWebGL": false 或修改 titleBarStyle 只是旁路试探，不能保证生效。
常见错误现象：改完 settings 重启 VSCode，navigator.gpu 仍返回对象，控制台仍有 GPU process crashed 日志——说明 GPU 进程仍在运行。
- 真正起效的唯一方式是启动前传参：
--disable-gpu - 该参数会跳过 GPU 进程创建，强制所有 UI 渲染走 CPU 软件光栅化路径
- 不影响终端、调试器、语法高亮、文件系统操作等核心功能
Windows/macOS/Linux 启动命令差异与永久配置
不同系统下命令格式和持久化方式不同，错一个字符就无效：
- Windows：右键快捷方式 → 属性 → “目标”末尾加空格再填
--disable-gpu（注意不是--disable-gpu=1或带引号） - macOS：终端执行
open -n -a "Visual Studio Code" --args --disable-gpu；若用code命令启动，需确保它是软链到 app 内部二进制，否则可能忽略参数 - Linux：直接运行
code --disable-gpu；若用桌面图标启动，需编辑~/.local/share/applications/code.desktop，把Exec=code %F改成Exec=code --disable-gpu %F
别信“在设置里搜 hardware acceleration 关掉就行”——那个开关只影响极少数合成行为（比如原生全屏），不是真正的 GPU 渲染开关。
遇到 WSLg、远程桌面或 Intel 核显必须加的组合参数
在 WSLg、旧版 Intel HD Graphics（如 HD 4000）、或 Windows 远程桌面连接中，单靠 --disable-gpu 有时还不够，GPU 进程虽不启，但底层仍尝试调用 OpenGL 接口导致崩溃重试循环：
- 追加
--disable-gpu-compositing：关闭 GPU 合成，防止图层混合异常 - 追加
--disable-software-rasterizer（慎用）：强制回退到更底层的 Skia CPU 光栅器，适合 Mesa 驱动 - 避免使用
--in-process-gpu：它把 GPU 进程塞进主进程，一旦崩溃直接杀死整个 VSCode，稳定性反而更差
验证是否真生效：启动后按 Ctrl+Shift+P → 输入 Developer: Toggle Developer Tools → 控制台执行 navigator.gpu，返回 undefined 才算成功。
禁用后仍闪烁？先排除扩展和驱动干扰
--disable-gpu 解决的是渲染管线级问题，但有些“闪烁”其实是插件或驱动残留行为：
- 运行
code --disable-extensions --disable-gpu：彻底排除插件干扰（尤其 Vim、Bracket Pair Colorizer、自定义主题类） - 检查显卡驱动：Ubuntu 上运行
glxinfo | grep "OpenGL renderer"，若显示mesa llvmpipe是纯软件渲染，没问题；若显示nouveau或radeon且版本老旧（ - 别依赖设备管理器自动更新：Windows 上它常装微软 WHQL 签名但已停更的驱动，应去 NVIDIA/AMD 官网下对应架构的最新稳定版（如
nvidia-driver-535）
真正难搞的不是参数本身，而是你得意识到：VSCode 的“界面”本质是嵌入式浏览器窗口，它的崩溃往往不在代码里，而在显卡驱动和内核图形栈的缝隙中——所以验证必须落到 navigator.gpu 和任务管理器/进程列表里有没有 GPU 进程这两件事上。
