VSCode对超大文件格式化超时无法通过调高timeout解决，因其本质是语言服务器主动禁用格式化能力，而非单纯等待超时；文件被识别为大文件后，LSP不启动，所有相关timeout配置均无效。
VSCode 对超大文件（如 >100MB 日志、JSONL、转储）执行格式化时，常因语言服务卡在语法解析或 AST 构建阶段而触发 formatting timed out 错误，本质不是“格式化慢”，而是语言服务器主动放弃——它根本没打算处理这个文件。
为什么 format 超时无法通过调高 timeout 解决
VSCode 的格式化超时（如 Formatting has timed out）通常来自语言服务器（LSP），而非编辑器本身。关键点在于：一旦文件被识别为“大文件”，VSCode 会主动禁用语言服务（包括格式化能力），此时修改 "editor.formatOnSaveTimeout" 或 "html.format.timeout" 等参数完全无效——服务压根没启动。
- 语言服务在检测到
files.maxMemoryForLargeFilesMB阈值被突破后，直接跳过初始化 - 即使你手动启用某扩展（如 Prettier），它也会读取 VSCode 的
isLargeFile标志并拒绝工作 - 错误日志里常见
Skipping formatting for large file或Language client is not ready
强制跳过格式化检查的三种可靠方式
目标不是“让格式化成功”，而是“不让它尝试”。以下方法均绕过 LSP 启动逻辑：
- 打开文件后，立即点击右下角语言标识（如
JSON），切换为Plain Text—— 这是最轻量且 100% 有效的兜底操作 - 用命令行只读打开：
code --read-only --disable-extensions /path/to/huge.json，--disable-extensions可阻止 Prettier/ESLint 等插件注入格式化入口 - 在
settings.json中为特定类型禁用格式化："[json]": { "editor.formatOnSave": false, "editor.formatOnType": false }注意：该配置仅在语言服务已启用时生效，所以需配合Plain Text切换使用
哪些设置看似相关实则无效
这些选项常被误认为能“延长格式化时间”，但它们对大文件场景无实质作用：
-
"editor.formatOnSaveTimeout"：仅影响已连接的语言服务，大文件下服务未连接，该值不参与任何逻辑 -
"files.autoGuessEncoding"：关闭它可加速加载，但不影响格式化流程本身 -
"editor.largeFileOptimizations"：设为false不会恢复格式化能力，反而可能让编辑器直接卡死 -
"files.maxMemoryForLargeFilesMB"：调高它（如设为4096）仅放宽“是否视为大文件”的判定，但若文件仍超过语言服务器自身内存阈值（如 TypeScript Server 的 2GB 限制），格式化照样失败
真正需要格式化时该怎么办
如果必须对超大文件做结构化处理（比如美化一个 500MB 的 JSON），不要依赖 VSCode 内置格式化：
- 终端流式处理：
cat huge.json | jq '.' > pretty.json（jq支持流式解析，不爆内存） - 分块处理：用
split -l 50000 huge.json part-拆分后逐个格式化，再cat part-* > final.json - 换工具：Sublime Text 或 Notepad++（Windows）对单文件格式化支持更鲁棒，不强依赖 LSP
记住：VSCode 的“大文件模式”是只读降级，不是性能调优。想让它格式化，等于要求一辆自行车拖动火车车厢——方向错了，再调参数也没用。
