应优先用字符串遍历替代正则：固定子串查找、固定位置提取、前缀校验、低匹配率大文本扫描、避免.*开头、需细粒度控制、内存受限、正则已成性能瓶颈且难优化时。

当正则表达式开始拖慢程序，或者你发现匹配耗时波动极大、偶发卡顿甚至超时，就该考虑回归基本的字符串遍历了。这不是倒退，而是对场景的精准判断——正则强大，但不万能；简单循环在特定任务下更可控、更稳定、更易预测。

匹配目标非常明确且结构固定

比如只找某个固定子串（如"user_id="）、提取固定位置的字符（第5–10位是订单号）、或校验是否以某前缀开头。这些任务不需要回溯、不涉及分支、也不依赖上下文。

• 用.indexOf()或.includes()（JavaScript）或str.find()（Python）比re.search(r"user_id=")快一个数量级，且无编译开销
• 提取固定偏移字段：直接text[5:10]比写r".{4}(\w{5})"更轻量、零回溯风险
• 前缀校验：str.startsWith("HTTP/")比re.match(r"^HTTP/")省去模式解析和状态机初始化

输入长度大但匹配概率极低

例如扫描日志文件查找罕见错误码，99.9%的行都不含目标。正则引擎仍会逐字符推进、尝试各种路径，而朴素遍历可在第一次失配时立即跳过整段。

• 对超长文本做“是否存在某单词”判断，"keyword" in text（Python）或text.indexOf("keyword") !== -1（JS）通常比/.keyword./更快，尤其在未命中时
• 避免用.*开头的模式扫描大文本——它强制引擎从头尝试所有可能起点，极易触发深度回溯
• 若必须用正则，优先用search()而非findall()，并配合text[:max_scan_len]限制范围

需要细粒度控制或中间状态

正则是一次性黑盒操作；而手动遍历可随时中断、记录位置、累积上下文、或动态调整逻辑——这对协议解析、词法扫描、流式处理很关键。

• 解析CSV中带引号转义的字段：正则易出错且难调试；逐字符状态机（如记录是否在引号内、是否遇到转义符）更可靠
• 实时输入校验（如密码强度）：边输入边统计数字/大小写字母个数，比每次触发完整正则匹配响应更快
• 内存受限环境（如嵌入式JS）：避免正则引擎的额外内存分配，纯循环只用几个变量

正则已成性能瓶颈且难以优化

当你已经尝试预编译、加锚点、拆分模式、避免嵌套量词，但最坏情况仍超时，说明问题不在写法，而在范式本身。

• 典型信号：用timeit或console.time测出正则在“恶意输入”（如"a" * 10000 + "b"配a*?b）下耗时突增数十倍
• 对比测试显示，朴素循环在相同数据集上始终稳定在亚毫秒级，而正则方差极大
• 团队成员频繁因正则回溯导致线上告警，且新成员难以理解复杂模式逻辑