VS Code打开大JSON或日志文件卡死本质是默认全量加载+语法高亮+搜索索引导致渲染线程夯住,与插件无关;有效解法是用code --disable-extensions --disable-gpu启动后执行File: Open Large File Optimized,或配置"files.maxMemoryForLargeFilesMB": 50和"files.associations": {"*.log": "plaintext"}跳过语法分析。

打开大 JSON 或日志文件时卡死,大概率不是插件问题
VS Code 默认对文件做全量内存加载 + 语法高亮 + 搜索索引,200MB 的日志文件直接让渲染线程夯住,连右键菜单都点不出来。这种卡死和插件无关,是编辑器自身机制导致的。
临时绕过方法:code --disable-extensions --disable-gpu 启动后,再用命令面板执行 Developer: Toggle Developer Tools,切到 Console 输入:
document.querySelector('monaco-editor')._instantiationService._serviceCollection.get(1)._service._model._value.length
能快速确认是否真被文件体积拖垮。真正有效的解法是配置限制:
- 在
settings.json中加"files.maxMemoryForLargeFilesMB": 50(默认是 40,设太小会禁用高亮) - 对已知大文件类型加
"files.associations": {"*.log": "plaintext"},跳过语法分析 - 禁用相关语言服务:比如关掉
json.validate.enable,避免 JSON Schema 校验阻塞
特定后缀文件保存时卡顿,重点查格式化插件激活逻辑
比如保存 .ts 文件时卡 2–3 秒,或按 Ctrl+S 后光标冻结,常见于 esbenp.prettier-vscode 和 dbaeumer.vscode-eslint 同时启用且都设为默认格式器。
它们会在保存瞬间触发两次同步调用,而其中一次可能因配置缺失(如没装 prettier CLI 或 eslint 本地依赖)卡在 spawn 等待上。控制台里常看到:
ERR! spawn ENOENT: Error: spawn eslint ENOENT
排查步骤:
- 运行
Developer: Show Running Extensions,看Activation Time是否异常高(>1500ms),尤其注意状态为Activating的插件 - 检查
editor.formatOnSave是否开启,并确认[typescript]块里只指定一个格式器,例如:"[typescript]": {"editor.defaultFormatter": "esbenp.prettier-vscode"} - 终端进项目根目录,手动运行
npx prettier --version或npx eslint --version,验证 CLI 是否真可用
打开 .py 文件就卡住,别急着卸载 Python 插件
ms-python.python 在无 pyproject.toml 或 requirements.txt 的目录下,仍会尝试启动完整 Python 环境、查找解释器、初始化 LSP —— 这个过程在低配远程机器上可能耗时数秒甚至超时挂起。
更隐蔽的问题是它和 Remote-SSH 插件配合时,若远程 ~/.vscode-server 权限错误(比如被 root 写入),会导致 Python 扩展反复重试初始化却始终失败,UI 线程卡在“正在加载扩展”不动。
可操作建议:
- 先执行
code --disable-extensions,确认是否恢复;若恢复,再单独测试code --disable-extension ms-python.python - 远程服务器上检查:
ls -ld ~/.vscode-server,确保属主是当前用户,否则chown -R $USER:$USER ~/.vscode-server - 禁用非必要子功能:在设置中关闭
python.languageServer(改用Pylance)、关掉python.testing.pytestEnabled等自动探测项
Remote-SSH 连接后打开任意文件都卡,优先检查锁文件和 Node.js 兼容性
Remote-SSH 插件卡在 Acquiring lock 或反复提示 Extension host terminated unexpectedly,往往不是网络问题,而是远程端服务环境异常。
典型现象包括:
- 本地 VS Code 是 Node.js v18,远程
~/.vscode-server/bin/xxx/下的二进制却依赖 v16,导致扩展宿主进程启动即崩溃 -
~/.vscode-server/data/Machine下残留.lock文件未释放,新连接被阻塞 - 远程
/etc/ssh/sshd_config中AllowTcpForwarding no,阻止了 VS Code 必需的端口转发
快速清理命令(远程执行):
rm -f ~/.vscode-server/data/Machine/*.lock<br>rm -rf ~/.vscode-server
之后重新连接,VS Code 会自动重传并安装匹配的 server 版本。如果仍报错,检查 ~/.vscode-server/bin/xxx/node 是否可执行,以及 node --version 输出是否与本地兼容。
真正容易被忽略的是:Remote-SSH 插件本身不报错,但它的子进程(比如 Python 或 Codex 后端)一旦因 DLL 初始化失败或 XML 解析异常退出,VS Code 不会明确提示,只会卡在 Loading —— 此时必须看 Output → Log (Remote Server) 面板最底部的真实错误行。


















