notepad++ 打开大日志卡死主因是默认启用可写模式预解析，需命令行启动+关自动换行/高亮/折叠+手动确认只读；超1.5gb应切片处理。
Notepad++ 打开大型日志文件卡死，不是内存不够或软件老化，而是它默认把 1GB 的 access.log 当成可编辑的 Python 脚本在解析——关掉三件事就能秒开：自动换行、语法高亮、代码折叠，再强制走只读路径。
怎么让 Notepad++ 真正启用稀疏加载
稀疏加载（Partial Loading）机制本身是有效的，但只在「只读 + 无解析」条件下触发。一旦用「文件 → 打开」弹出标准对话框，Notepad++ 就会启动可写模式预扫描：构建行号索引、做 UTF-8→UTF-16 转换、预留 undo 缓存——512MB 文件实际内存占用直接飙到 2.1GB，UI 线程彻底挂起。
- 必须用
notepad++.exe "D:\logs\app.log"命令行启动（路径加英文引号），或直接拖拽文件到 Notepad++ 窗口 - 拖入后若弹出
src/bigfilemessage.ui提示框，必须手动点一下（选 No[Drop] 即可），否则界面永久假死 - 右键菜单里「在 Notepad++ 中以只读方式打开」比「打开」更可靠，它跳过文档可写性检查
- 中文路径、全角空格、波浪号（~）会导致多文件静默丢弃，测试前先复制到
C:\tmp\这类纯英文短路径
为什么关掉自动换行比关高亮还关键
自动换行 看似只是 UI 设置，实则会强制 Scintilla 引擎对每一行做宽度计算和折行缓存。遇到带堆栈的 Java 日志（单行超 10KB），它会提前加载整行内容，直接破坏稀疏加载的“按需加载可见区”逻辑。
- 操作路径：视图 → 自动换行（取消勾选）
- 效果实测：1.2GB 的
access.log打开时间从 45 秒压到 3 秒内 - 副作用只有横向滚动条出现，但日志分析本就不靠逐行阅读，而是靠搜索跳转
- 别只关高亮——插件如
JSON Viewer会偷偷启用 token 分析，务必在分析前禁用全部插件
正则搜索快 50 倍的写法和陷阱
Notepad++ 的正则引擎支持行首优化，但只要漏掉 ^ 或用了 .* 开头，就会退化成逐字节暴力匹配。500MB 文件搜索耗时可能从 0.8s 暴涨到 47s+。
- 安全写法：用
^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:锚定时间戳，这是日志分析的底线 - 避免
.*ERROR，改用[^\n]{0,200}ERROR限定匹配宽度 - 多关键词用
error|warn|fail，比开“匹配大小写”+三次搜索快 3 倍（PCRE 单次编译复用） - 搜索前先按
Ctrl+G跳到大致行号（如 1000000），避免从头渲染；再用「搜索 → 查找 → 勾选标记行 → 查找全部」，匹配行自动加书签，不生成渲染标记对象
真正容易被忽略的是：超过 1.5GB 就不该硬扛。v8.5.9 及之前版本在此量级已不是“慢”，而是不可靠——SCI_SETTEXT 阻塞、WM_PAINT 消息积压超万条、点 × 都关不掉。这时候花 10 分钟调参数，不如 30 秒用 head -n 500000 app.log > sample.log（WSL）或 PowerShell 的 Get-Content app.log -Head 500000 | Set-Content sample.log 切出目标段落再处理。
