Sublime启动闪退大概率是缺失共享库所致；终端执行ldd命令可确认libgtk-3.so.0、libglib2.0-0等依赖是否未找到，需手动安装对应运行时库而非仅开发包。
Sublime启动闪退是否由缺失共享库引起
Linux下Sublime启动后瞬间消失（进程存在不到1秒），且sublime_text命令在终端无任何输出，大概率是动态链接失败——即找不到关键共享库，比如libgtk-3.so.0、libgdk-3.so.0或libnss3.so。这不是Sublime自身bug，而是系统缺少运行时依赖。
验证方法：终端执行ldd /opt/sublime_text/sublime_text | grep "not found"，出现任何not found行即确认问题根源。
- 常见缺失项：
libglib2.0-0、libgtk-3-0、libnss3、libxss1（尤其Kali/Debian新版本默认不装libglib2.0-0） - Debian/Ubuntu/Kali用户注意：
libglib2.0-0在某些最小化安装中被移除，但Sublime 4必须依赖它 - 不要只装
libglib2.0-dev——那是开发头文件，运行时需要的是libglib2.0-0
apt安装缺失依赖的正确顺序
直接sudo apt install -f往往无效，因为Sublime的.deb包未被apt完全识别。必须手动按依赖层级安装，否则会循环报错“无法满足依赖”。
- 先更新源：
sudo apt update - 一次性装全核心依赖：
sudo apt install libglib2.0-0 libgtk-3-0 libnss3 libxss1 libasound2 - 若提示
libglib2.0-0版本冲突（如系统有libglib2.0-0:amd64 (2.74.5-1)但Sublime要求2.72+），不用降级——新版完全兼容，忽略警告继续 - 装完后不重启，直接终端运行
/opt/sublime_text/sublime_text --no-sandbox测试是否能拉起窗口（绕过沙箱可排除另一类崩溃）
为什么sudo apt --fix-broken install常失效
该命令只修复apt数据库里已知的损坏包，而Sublime是独立.deb安装、未录入apt依赖图谱。它看到sublime-text包状态为“installed”，就认为一切正常，不会主动检查其ldd依赖链。
- 典型表现：执行
sudo apt --fix-broken install后返回“0 upgraded, 0 newly installed”，但Sublime依然闪退 - 真正有效的修复是让apt“意识到”这些库是Sublime的硬依赖——用
dpkg -I sublime-text_*.deb | grep Depends查看官方包声明的依赖项，再对照安装 - 如果你用的是从官网下载的
.deb包，别用gdebi静默安装——它会跳过依赖检查，应改用sudo apt install ./sublime-text_*.deb，这样apt才能介入依赖解析
闪退但控制台有Python错误？那不是依赖问题
如果终端运行sublime_text后出现大量ImportError或plugin_host has exited unexpectedly，说明进程已启动成功，问题出在插件层而非系统库。此时ldd检查必然通过，强行重装libglib2.0-0毫无意义。
- 立刻按
Ctrl + `调出Sublime控制台，看首条错误是否指向某个插件路径（如./Packages/GitSavvy/...） - 临时禁用所有插件：
mv ~/.config/sublime-text/Packages/{*,.??*} ~/.config/sublime-text/Packages-backup/ 2>/dev/null，再启动测试 - 别信“重装Sublime就能解决”——90%的插件崩溃在重装后原样复现，因为用户数据目录没清
最易被忽略的一点：Kali Linux 2026.1之后默认启用systemd-oomd内存杀进程机制，Sublime启动时若瞬时内存占用超阈值（尤其开大文件+插件），会被无声kill。查journalctl -u systemd-oomd | grep sublime确认，临时关闭用sudo systemctl stop systemd-oomd。
