plugin_host cpu拉满是因插件高频输出日志导致其反复解析渲染控制台文本流，而非执行命令；关闭控制台窗口可立即缓解，禁用lsp/sublimelinter/gitgutter等日志源插件并设置console_max_lines和log_level可根治。
为什么plugin_host在控制台高频输出时CPU拉满
Sublime Text 的 plugin_host 进程不是在“执行命令”，而是在反复解析、渲染、缓冲控制台（Ctrl+`）里涌进的日志流——尤其是 LSP、SublimeLinter 或自定义插件持续打印 traceback、starting...、restarting server 这类短行高频日志时，Python 插件层会为每条日志做字符串处理、颜色标记、滚动定位、历史缓存，最终压垮单核 CPU。
这不是 bug，是设计使然：控制台本质是个带语法高亮的实时文本视图，没有节流、无日志采样、不丢弃旧行。一旦插件失控输出，plugin_host 就变成纯 IO + 字符串操作的死循环。
- 典型现象：控制台卡住不动，但
plugin_host占用 90%+ CPU，编辑器界面输入延迟、光标闪烁变慢 - 验证方式：关闭控制台窗口（不是清空内容），
plugin_hostCPU 几秒内回落；再打开，立刻回升 - 注意：
View → Hide Console只隐藏 UI，日志仍在写入缓冲区；必须关掉窗口本身才释放压力
快速止血：临时禁用日志源头插件
别先调设置，先让 CPU 降下来。高频日志几乎全来自三类插件：LSP-pyright、SublimeLinter、GitGutter。它们在项目加载失败、服务器崩溃循环、或文件状态轮询异常时，会把错误堆成瀑布。
- 打开
Preferences → Package Control → Disable Package，按顺序禁用：LSP→SublimeLinter→GitGutter - 每禁用一个，观察
plugin_hostCPU 是否明显下降（任务管理器或活动监视器） - 确认元凶后，不要直接卸载——先查控制台里最后一段报错，比如：
ERROR: pylsp crashed, restarting...或git status failed: exit code 128 - 常见根因：
node_modules路径过深导致 LSP 初始化超时、Git 仓库权限异常、Linter 配置了不存在的二进制路径
长期规避：限制插件日志量与控制台行为
关掉日志不是办法，得让插件“少说话”，也让控制台“别太勤快”。这两项配置加进用户设置（Preferences → Settings）即可生效：
{
"console_max_lines": 500,
"log_level": "error"
}
-
"console_max_lines": 500：强制控制台只保留最近 500 行，老日志自动丢弃，大幅降低内存与渲染压力 -
"log_level": "error"：全局将插件日志级别设为 error，屏蔽 info/warning 级别输出（LSP、Linter 等插件大多支持该字段） - 对 LSP 用户：在
Language Server Configuration里单独关掉 verbose 日志，例如 pyright 的"logVerbosity": "normal"改为"none" - 避免使用
print()调试插件——改用sublime.status_message()或写入临时文件
控制台本身不是问题，但它是放大器
控制台从不主动消耗 CPU，它只是把插件塞过来的每一行都“如实呈现”。真正吃资源的是背后插件的输出节奏和 Sublime 对文本流的无差别处理。很多人花时间调 font_options 或关 antialias，其实完全跑偏——只要日志源头没控住，换再轻量的字体也救不了 plugin_host。
最易被忽略的一点：plugin_host 是 Python 进程，它的 GC 和字符串池在高频短日志下极易碎片化，重启 Sublime 才是唯一彻底释放的方式；单纯关闭再打开控制台窗口，残留缓冲仍会缓慢拖累。
