sublime 的 find all 会因全量加载匹配结果而假死，应改用窄范围正则、段落内操作、grep 预筛选、安全模式排查插件，并注意编码与换行符问题。
Find All 一点击就假死？别让它全量加载匹配结果
Sublime 的 Find All 不是“找完再显示”，而是把所有匹配行的高亮、选区、跳转索引一次性塞进内存。2GB 日志里搜 ERROR，匹配几十万行，它真会卡住几分钟——不是硬盘慢，是 Sublime 在拼命建 DOM 节点。
- 先用
Ctrl+R（Replace）面板，勾选Regular Expression，写窄范围正则：删空行用^\s*$\n?，而不是.*全局贪婪匹配 - 按
Ctrl+Shift+P→ 输入Selection: Expand Selection to Paragraph，只选中当前段落再Ctrl+H替换，避开全文件扫描 - 点
Find All前务必看右下角匹配数：如果显示128456 matches，就别点Replace All，改用Replace逐个确认
grep + Sublime 组合拳比 Find in Files 实在
Find in Files 会为每个匹配行加载整行内容、做语法着色、维护跳转链路，对大文件是灾难。而终端 grep -n 只输出行号和文本片段，零渲染开销。
- 查最近 500 条 error：
tail -n 5000 app.log | grep "ERROR" | head -n 500 > errors_recent.log - 精准定位某行：
grep -n "session_id=abc123" huge.log | head -1得到123456:...，再在 Sublime 里按Ctrl+G输入123456直接跳转 - 避免
Find in Files扫全量目录：尤其当项目含node_modules或日志归档时，它真会扫上万文件
正则替换后保存失败？编码和换行符在捣鬼
保存时报 Unable to save … No space left on device，大概率不是磁盘满了，而是 Sublime 在保存时偷偷做换行符转换或 BOM 处理，导致缓冲区溢出。
- 保存前点右下角
UTF-8和Unix (LF)，手动选稳了再存 - 别用
Save with Encoding，改用File → Reopen with Encoding → UTF-8，再Ctrl+S - 若文件混有非法字节（比如二进制头），Sublime 会静默截断；先用
file -i huge.log或xxd -l 32 huge.log确认纯文本 - 实在不行，
Ctrl+N新建窗口 →Ctrl+V粘贴内容 → 另存为，绕过原文件锁和缓存逻辑
插件在后台偷偷扫全文？安全模式是诊断开关
关了语法高亮、行号，还是卡？很可能是 SublimeLinter、GitGutter 这类插件在你没注意时 fork 子进程扫全文——它们不认 large_file_size_limit，也不听你手动切 Plain Text。
- 终端执行
subl --safe-mode huge.log：跳过所有插件和用户设置，如果秒开，问题就出在插件 - 临时禁用可疑插件：
Package Control: Disable Package→ 关掉SublimeLinter、GitGutter、BracketHighlighter - 别信“已禁用”：有些插件残留进程仍在跑，必须重启 Sublime 才彻底释放
grep 就用，该拆分就拆分，该切 less 就切。
