VSCode测试运行时CPU占用高但响应卡顿，是因为测试子进程继承默认调度优先级，被系统排在UI线程之后，导致光标卡顿、保存延迟；需通过preLaunchTask配合nice/start /high调整优先级，并禁用integratedTerminal、关闭tsserver自动类型获取和Git自动仓库检测等后台争抢行为。
为什么测试运行时 CPU 占用高但响应卡顿
VSCode 运行测试（尤其是 Jest、pytest 或 CTest）时，testExplorer 或 Python Test Adapter 启动的子进程默认继承主进程的调度优先级，而 Node.js/Python 进程本身不主动设为 realtime 或 high 优先级。结果就是：CPU 核心被占满，但操作系统将测试进程排在编辑器 UI 线程之后调度，导致光标卡顿、文件保存延迟、甚至 Code Helper (Renderer) 崩溃。
如何在 launch.json 中设置测试进程的 CPU 优先级
VSCode 的 launch.json 不直接支持 nice 或 start /high，但可通过 env + preLaunchTask 绕过限制：
- Linux/macOS：在
preLaunchTask脚本中用nice -n -5启动测试命令，例如：nice -n -5 npm test - Windows：用
start /high包裹命令，注意需启用cmd /c并避免路径空格引发解析错误，例如：cmd /c "start /high npm test" - 必须禁用
console: "integratedTerminal"，否则优先级会被终端模拟器重置；改用"console": "externalTerminal"或"console": "none" - 若使用
jest --runInBand，优先级生效更稳定；并发模式（--maxWorkers）下各 worker 进程需单独调优
测试框架自身对调度的影响
不同框架默认行为差异极大：
-
Jest在 v29+ 默认启用worker_threads，但线程池不继承父进程优先级，需配合jest --detectOpenHandles --runInBand避免竞争 -
pytest的-j参数启动的子进程默认是normal优先级，需用pytest --forked+os.nice(-5)在 conftest.py 中手动调整 -
CTest（CMake）无内置优先级控制，必须在ctest -jN外层包裹nice -n -10 ctest -jN - 所有框架在 WSL2 中受 Linux 内核调度器影响更大，
chrt -r 50（SCHED_FIFO）比nice更有效，但需 root 权限
容易被忽略的冲突点
真正拖慢体验的往往不是测试本身，而是 VSCode 后台服务与测试进程争抢资源：
-
typescript.tsserver在测试运行期间仍持续扫描node_modules，建议临时关闭："typescript.preferences.disableAutomaticTypeAcquisition": true - Git 扩展的自动刷新（
git.autoRepositoryDetection）会在测试输出大量文件变更时触发高频 fs watch，应设为false或排除build/dist/ - 如果用了 Dev Container，
devcontainer.json中未配置"runArgs": ["--cpus=3"]，容器内多进程会抢占全部 CPU，导致宿主机 UI 响应停滞 - Windows 上
antimalware service executable常在测试生成大量临时文件时突然扫描，建议临时添加node_modules/和构建目录到 Defender 排除列表
