立刻让大文件变流畅：先设语法为纯文本，再关行号，最后右下角设同后缀默认为纯文本；仅对大日志等文件禁用行号、装订线和高亮行；large_file_size_limit 设100MB最合理；插件如SublimeLinter、GitGutter仍会拖慢，需安全模式验证并禁用。
怎么立刻让已打开的大文件变流畅
文件已经卡死不动？别等加载完成，也别重启 Sublime，直接打断正在运行的语法解析链：Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（macOS），输入 Set Syntax: Plain Text 回车——语法高亮引擎立刻停止逐行正则匹配；再输 View: Toggle Line Numbers 关掉行号，避免为百万行生成 DOM 节点；最后右下角点击当前语法名（如显示 JSON 或 Log），选 Open all with current extension as… → Plain Text。这三步做完，滚动基本恢复，且下次同后缀文件自动继承该行为。
为什么全局关 line_numbers 是错的
你不需要所有文件都失去行号，日常写 python 时仍需定位；但打开 access.log 时就得静默加载。全局设 "line_numbers": false 会反向拖慢开发效率。正确做法是：打开一个大日志文件，确认右下角显示为 Plain Text 或 Log，执行 Preferences → Settings – Syntax Specific，生成对应语法的配置文件（如 Plain Text.sublime-settings），在里面写入：
{"line_numbers": false,"gutter": false,"highlight_line": false}
这样只对纯文本类文件生效，不影响其他语法上下文。
large_file_size_limit 设多少才合理
这个值不是越大越好，也不是越小越安全，而是要卡在“真正需要轻量加载的文件”和“日常可编辑的小文件”之间："large_file_size_limit": 100（单位 MB）是实测平衡点。设太小（如 50）会让 package.json、tsconfig.json 这类日常文件也被误判为大文件，失去折叠、跳转等编辑能力；设太大（如 1000）则可能错过真正要查看的 120MB 日志，导致它仍被当代码全量解析。注意：该配置只影响后续新打开的文件，不改变已打开行为。
哪些插件会在语法关闭后继续拖垮性能
即使你手动切到 Plain Text 并关掉高亮，某些插件仍会偷偷扫描整份文件：SublimeLinter 默认对每个打开的文件跑 lint，不识别“大文件”概念；GitGutter 会逐行比对 Git 状态，在百万行日志里每行都触发 diff 计算；BracketHighlighter 光标悬停就尝试匹配括号，长行里正则回溯直接卡死。验证是否是插件导致：终端执行 subl --safe-mode huge.log，如果秒开，问题就出在插件。临时禁用方法：命令面板输入 Package Control: Disable Package，选中可疑项即可。
最常被忽略的是：语法设置只是入口，真正卡顿往往来自后台索引、缩进检测、插件扫描这些“看不见的进程”。关语法只是按下暂停键，关 index_files 和 detect_indentation 才是拔掉电源线。
