几十 MB 的日志，拖进编辑器要么卡到转圈、要么直接让标签页崩溃；VS Code 全局搜索对超大单文件也未必扛得住。命令行 grep 当然行，但你想边调正则边看高亮、还想顺手导出结果时，来回敲命令并不顺手。Regex Pro 的文件流式扫描模式填的就是这个空档：拖一个大文件进去，正则在 Web Worker 里分块跑，grep 风格带上下文展示命中，全程不冻页面。
两种模式，按文件大小自动切
| 小文本（直接编辑） | 大文件（流式扫描） | |
|---|---|---|
| 触发 | < 约 2MB | > 约 2MB，或拖入大文件 |
| 文本去向 | 读进编辑器 DOM | 不进 DOM，Worker 分块读 |
| 命中展示 | 完整捕获组明细 + 位置 | grep 风格，带上下文行高亮 |
| 能做 | 匹配 / 替换 / 统计 / 测试 | 快速定位 + 上下文 |
| 持久化 | 缓存到 localStorage | 不持久化（刷新即清） |
你不用手动选——点「📁 打开文件」或直接把文件拖进测试文本区，工具按大小自动判断。为什么要分：把几十 MB 文本塞进 DOM 编辑器，光渲染和高亮就能拖垮浏览器；流式模式绕开”全量进 DOM”，所以几十 MB 也不卡。退出回普通编辑，点文件栏的「关闭文件」。
grep 风格的命中：要的就是上下文
流式模式下，每条命中显示所在行的上下文、命中片段高亮——一眼看到”匹配落在哪行、周围是什么”。排障时这远比只给”匹配到的几个字符”有用：
…
[10:01:24] WARN retry attempt 2 for /api/order/list
[10:01:24] ERROR upstream timeout /api/order/list cost=5012ms ← 命中高亮
[10:01:25] INFO circuit-breaker opened for order-service
…复杂的全量捕获组聚合在流式模式下受单次收集上限影响。实用策略是两种模式接力：
先用流式模式在大日志里 grep 出目标行 → 复制这批结果 → 粘进编辑区当小文本 → 再做精细的捕获组提取 / 统计 / 替换。
流式 ≠ 免疫卡死：正则本身得先线性
流式解决的是”文本太大塞不进界面”，不解决”正则是灾难性回溯炸弹”。线性安全的正则扫几十 MB 没问题；但 (a+)+$ 这类指数回溯的正则，在大输入上照样能炸，输入越大引信越长。
工具给 Worker 设了约 4.5 秒超时（线性扫描留足余量，灾难性回溯会很快触发并被拦下、重建 Worker），最坏是”超时”而非冻死页面。上大文件前的规矩：先用一小段样本在普通模式「⏱ Bench」确认正则线性，再放大文件。把 .* 换成 [^x]*、拍平嵌套量词——这些优化在大文件上收益最明显。（回溯成因与改写详见关于 ReDoS 的姊妹篇。）
隐私：本地跑，但别点分享
Regex Pro 是纯静态工具，匹配跑在浏览器 Web Worker 里，文件内容不经过任何服务器——这是它能处理敏感内部日志的前提。两条边界记牢：
- 大文本不写 localStorage：小文本会缓存（刷新后还在），但大文件和超长文本（> 约 1MB）刻意不持久化——刷新 / 关页面后需重新打开。这既是性能考虑（同步序列化几十 MB 会冻主线程、撑爆 5–10MB 配额），也顺带降低敏感数据残留。
- 分享别带敏感内容：状态栏「📤 分享」会把 pattern 和文本编进 URL，大文件 / 敏感日志不要用分享功能——那等于把内容写进链接。
命中太多 / 想导出
- 收紧正则：加
^（配m多行逐行）、更具体的字符类、用断言排噪声行，把命中从几万降到几十条。开「· 空白」显示空白字符，看清行尾空格 / 制表符，写出更精准的过滤。 - 导出：「匹配列表」头部有「复制全部」「导出 JSON」「导出 CSV」。要把命中连同捕获组导成表格，用 导出 CSV（Excel 直接打开）。
需要”每接口耗时均值 / P99”这类聚合，把目标行复制进普通模式走「统计」面板——一条正则把日志算成数据表，那是另一篇的主题。大文件 grep 负责”快速圈定现场”，统计面板负责”把现场算成数”，配合起来就是一套不开 IDE、不导数据库的轻量排障流。