VSCode运行高并发测试时卡死，是因为测试子进程默认继承normal调度优先级，被系统排在UI线程之后，导致光标冻结、保存延迟；需通过preLaunchTask配合nice/start /high提升优先级，并禁用integratedTerminal、关闭tsserver类型获取和Git自动检测等后台争抢行为。
VSCode 运行大量并发测试时终端卡死，不是 Node 本身太慢，而是测试进程和编辑器 UI 线程争抢 CPU 调度权——测试子进程默认继承 normal 优先级，被系统排在 Code Helper (Renderer) 后面，导致光标冻结、保存延迟甚至崩溃。
为什么 code --status 显示 CPU 100% 但编辑器“看起来还活着”
这是典型的调度饥饿现象：Node 测试进程（如 jest、pytest、ctest）占满 CPU 核心，但操作系统不给它调度时间片，UI 线程反而因得不到响应而卡顿。此时 code --status 里 Extension Host 或 Renderer 的 CPU% 可能不高，但 Shared Process 或 Search 却异常活跃——因为 Git 自动检测、文件监听、遥测等后台任务仍在争抢资源。
- 运行
code --status后重点关注带jest、pytest、ctest字样的进程，记下 PID；再用ps -p [pid] -o pri,nice,comm=（macOS/Linux）确认其调度优先级是否为20（normal） - Windows 上打开任务管理器 → “详细信息”页 → 右键对应进程 → “设置优先级” → 查看是否为“正常”
- 若测试输出中夹杂大量
EMFILE、ENOSPC或Too many open files，说明文件描述符耗尽，常由inotify+ 测试日志轮转共同触发
launch.json 里没法直接设 nice，怎么绕过限制
VSCode 的 launch.json 不支持原生调度参数，必须通过 preLaunchTask 注入 shell 层级控制。关键点是：不能让终端模拟器劫持优先级，且要避免空格路径解析失败。
- Linux/macOS：在
.vscode/tasks.json中定义 task，命令写成"command": "sh -c 'exec nice -n -5 npm test'"（注意exec防止 shell 进程残留） - Windows：用
cmd /c "start /high /wait npm test"，/wait确保调试器能正确 attach - 必须把
"console": "integratedTerminal"改成"console": "none"或"console": "externalTerminal"，否则终端会重置进程优先级 - 如果用 Jest，加
--runInBand参数，避免 worker_threads 创建的子进程丢失优先级继承
测试期间哪些 VSCode 后台服务最该关
语言服务器和 Git 扩展在测试输出大量文件变更时会高频触发 fs watch，比测试本身更耗 CPU。
- 临时关闭 TypeScript 全量索引：
"typescript.preferences.disableAutomaticTypeAcquisition": true - 禁用 Git 自动仓库检测：
"git.autoRepositoryDetection": false，或在项目级 settings 中排除build/、dist/ - 关掉 ESLint 实时校验：
"eslint.run": "onSave"（而非onType），并缩小eslint.probe范围，比如只保留["javascript", "typescript"] - 如果用 Dev Container，检查
devcontainer.json是否含"runArgs": ["--cpus=3"]；未设置时容器内多进程会抢占全部 CPU
真正卡死的临界点往往不是测试代码本身，而是 files.watcherExclude 没配或配错——比如漏掉 "**/coverage/**"，导致测试生成的几千个 lcov 文件持续触发 inotify 事件。这种问题不会出现在 code --status 的高 CPU 列表里，但会让整个工作区陷入“假死”。
