sublime text打开大bson文件闪退是因它将二进制bson当纯文本全载入内存导致oom被系统强制终止；正确做法是先用bsondump转json，再配合禁用index_files、切换plain text语法及安全模式排查插件。
Sublime Text打开大BSON文件直接闪退
这不是Sublime Text的bug，而是它根本没设计用来解析BSON——它把所有文件当纯文本加载进内存，而一个几百MB的BSON dump（比如MongoDB导出的collection.bson）解码后可能膨胀到数GB，触发Windows内存保护或OS强制终止进程。你看到的“一闪就消失”，其实是进程被系统杀掉，连错误日志都没来得及输出。
实操建议：
- 别用Sublime Text打开原始
.bson文件——它不是文本，也不是JSON，不能靠语法高亮“硬读” - 先用
bsondump（MongoDB官方工具）转成可读JSON：bsondump collection.bson > collection.json
再用Sublime打开collection.json（仍建议分块处理） - 如果必须查二进制内容，用
xxd或hexdump -C生成十六进制视图，Sublime能稳定加载这类固定宽度文本
用Sublime Text搜索大JSON（已转义BSON）时崩溃
即使转成JSON，单文件超100MB后，Sublime Text的搜索索引、正则匹配和语法解析模块会大量申请内存，尤其启用"index_files": true（默认开启）时，后台线程极易因OOM被系统回收。
实操建议：
- 临时关闭索引：在
Preferences.sublime-settings中设"index_files": false，重启生效 - 禁用语法高亮：右下角点击当前语法（如“JSON”），选“Plain Text”，避免解析器反复尝试结构校验
- 用
Ctrl+F时避开贪婪正则——比如不用.*，改用[^}]*限定范围；复杂模式优先交给ripgrep或jq命令行处理
插件在大BSON/JSON场景下加剧闪退
像SideBarEnhancements、BracketHighlighter或任何监听on_load事件的插件，会在文件打开瞬间执行大量同步操作。对大文件，它们不是“慢”，而是直接卡死主线程，触发Windows的Application Hang检测机制，强制kill进程。
实操建议：
- 启动时加
--safe-mode参数：sublime_text.exe --safe-mode collection.json
确认是否插件导致 - 检查控制台（
Ctrl+`）是否有ImportError: cannot import name 'create_connection'——这是Python API不兼容的典型信号，常见于老版本GitSavvy或SublimeLinter - 彻底停用非必要插件：进入
%APPDATA%\Sublime Text\Packages\，把除User外的文件夹全部重命名（如GitSavvy_bak），逐个恢复测试
替代方案比硬扛更可靠
Sublime Text的架构决定了它不适合BSON/大数据JSON场景。强行调优只是延缓崩溃，不是解决路径。
实操建议：
- 查结构用
jq：jq '.[0].field' collection.json
比任何GUI搜索都快且稳定 - 看局部内容用
less +/pattern或VS Code（它对大文件做了流式加载，不全载入内存） - 真要编辑？拆分文件：
split -l 10000 collection.json chunk_，处理完再cat chunk_* > merged.json
真正容易被忽略的是：BSON不是文本格式，所有试图“用文本编辑器硬开”的操作，本质都在绕过数据协议。闪退不是软件失灵，是系统在阻止你做一件它明确不支持的事。
