sublime text 4 默认常驻后台，关闭窗口不退出进程，导致配置未生效、lsp插件和同步服务持续运行；需通过任务管理器或killall彻底终止进程，并清理缓存、登出同步、放行防火墙才能真正退出。
为什么关了窗口 Sublime 还在后台跑着
Sublime Text 4 默认设计就是常驻进程，不是“用完即退”的传统桌面应用。窗口关闭只是隐藏 UI，核心进程（sublime_text.exe、subl 或 macOS 下的 Sublime Text）仍在运行，持续监听剪贴板、维持 LSP 连接、同步账号状态、甚至预热索引——这些功能全靠后台进程支撑。
subl 命令触发的复用机制让改配置失效
在终端执行 subl 打开文件时，Sublime 不会启动新进程，而是复用已存在的后台实例。这意味着：你刚在 Settings 里把 update_check 改成 false，但那个正在跑的旧进程根本没加载新配置。结果就是弹窗照出、状态栏照显、菜单项照在。
- Windows/Linux：任务管理器里搜
sublime_text.exe和subl.exe，必须全杀 - macOS：
killall "Sublime Text"比只关 Dock 图标更可靠 - 改完配置后不杀进程 = 白改
LSP 插件和同步服务是隐形进程源
像 pyright、texlab 这类语言服务器插件，卸载后仍可能在 Cache/ 目录下保留可执行文件或 socket 文件；而 subl --sync-login 登录过的账号，会让进程长期保活以轮询云端变更。这两类服务不依赖主 UI，即使没开任何窗口，ps aux | grep sublime 也能看到它们。
- 查残留：Linux/macOS 运行
ps aux | grep -i "sublime\|pyright\|texlab" - 清缓存：
Cache/下按插件名删整夹，别只删Packages/ - 登出同步：
subl --sync-logout是切断后台保活的关键一环
安全软件或系统级劫持导致进程“假死”
某些国产安全软件会拦截 sublime_text.exe 的网络请求，触发 Sublime 内部重试逻辑——它误判为“更新服务器不可达”，于是每 5 分钟重试一次，反复拉起 HTTP client 线程，表现为 CPU 占用不降、进程无法彻底退出。
- 临时禁用安全软件，观察进程是否真正消失
- 防火墙中放行
sublime_text.exe（Windows）或sublime_text（Linux） - 便携版用户注意：路径含空格或中文时，
subl命令可能解析失败，导致后台进程卡在僵死状态
subl 进程，它都可能在 10 秒后悄悄拉起新线程。
