终端滚动卡顿根因是GPU渲染线程被老旧驱动或虚拟化环境卡死，非显存不足；解决方法为添加--disable-gpu参数强制CPU渲染，并配合调整terminal.integrated.rendererType、scrollback等参数优化性能。
终端滚动条卡顿是 GPU 渲染线程被拖住，不是显存不足
VSCode 终端滚动卡顿、光标冻结、粘贴延迟，90% 不是显存爆了，而是 Electron 的 GPU 渲染线程被老旧驱动或虚拟化环境卡死。特别是 Windows 上 Intel 核显、WSL2 GUI、RDP 远程桌面场景，--disable-gpu 一加就立刻跟手——这不是降级，是绕过驱动 bug。
滚动条渲染模式选 dom 还是 canvas？看显卡类型
terminal.integrated.rendererType 控制底层渲染器，它直接影响滚动时的显存压力和帧率稳定性：
-
canvas：默认值，适合 NVIDIA/AMD 独显 + 新驱动，滚动顺滑但缩放非 100% 时易白屏/撕裂 -
dom：把每个字符当<span>渲染，CPU 负担略高，但对中文、emoji、宽字符混排更稳，显存波动小 - 某些插件（如实时命令提示）在
dom模式下位置错位，遇到就切回canvas+--disable-gpu组合
滚动性能三参数必须调，不能只靠默认
光改渲染器不够，scrollback、smoothScrolling、mouseWheelScrollSensitivity 共同决定滚动时的显存驻留峰值和重绘频率：
-
"terminal.integrated.scrollback": 1000：缓冲区从默认 10000 行砍到 1000，显存占用立降 60%+；日志类任务用less或tail -f替代长缓冲 -
"terminal.integrated.smoothScrolling": false：关掉 125ms 缓动动画，滚动响应从“视觉顺滑”变“指令即时”，对键盘党更跟手 -
"terminal.integrated.mouseWheelScrollSensitivity": 2：默认是 1，设为 2 可减少滚动事件触发频次，避免高频requestAnimationFrame拖垮渲染线程
GPU 显存下限不是靠“省”，而是靠“不预占”
终端本身不加载模型，但它会为 canvas 渲染器预分配 GPU 纹理内存。这个预分配是静态的，和实际内容无关。比如 1920×1080 分辨率下，canvas 渲染器可能预占 300MB 显存，哪怕你只显示 10 行文本。
- 唯一能压显存下限的方式：启动时加
--disable-gpu，强制走 CPU 渲染路径 -
terminal.integrated.gpuAcceleration设置为off没用——它只控制终端区域的合成层，不触底 Electron 的 GPU 初始化 - 验证是否生效：打开 DevTools → Console → 输入
process.argv，确认数组里有--disable-gpu
