文本与正则表达式

检查正则表达式是否匹配到所需内容

使用工具

正则找到一个目标值，就容易让人觉得完成了。更难发现的是误抓相似值或悄悄漏掉特殊行。先准备短文本和明确预期，再逐项加条件，比一开始写复杂表达式更容易维护。

这里使用虚构订单 ID。工具采用 JavaScript 正则，表达式和标志分开填写。处理敏感日志前，先用小例子区分完整匹配、捕获组和替换后文本。

目标文本

order-104
order-205
preorder-306
order-407x

先试此表达式，不加两端斜杠

order-([0-9]+)

使用 gm 标志会匹配四处：preorder-306 含 order-306，order-407x 以 order-407 开头。包含目标两项并不够，还缺少整行必须是订单 ID 的条件。

整行表达式，标志 gm

^order-([0-9]+)$

加 ^、$ 并用 gm 后，只剩 order-104 与 order-205。m 让锚点作用于各行边界；只有 g 没有 m 时，四行整体不是一个完整 ID，因而不匹配。全局匹配与多行锚点是不同功能。

SheepDev 当前会在内部补 g 来列出匹配，删掉它不会变成只测第一项。目标代码若只处理首项，应另行验证调用方式。同一表达式在不同 API 或标志下会有不同结果。

([0-9]+) 的括号捕获数字，完整匹配是 order-104，组 1 是 104，可适用于其他 ID 而非写死一个值。+ 至少要求一位数字，所以 order- 不匹配。是否允许空数字应另作规范决定。

此式不接受全角数字、正负号或分组符。若要允许 order-０１２，应明确条件并加测试。捕获到的 001 也不应自动转成数字 1，下游需保留标识语义。

替换字符串

ID:$1

锚定表达式与 gm 的替换结果

ID:104
ID:205
preorder-306
order-407x

$1 插入第一个捕获组，只把匹配的两行改成 ID:104、ID:205，其他行保留。要区分只取捕获值，还是改写原文。把替换结果误作提取列表，就会觉得排除行又混进来了。

新增捕获括号可能改变组编号，修改表达式后要重新检查替换引用，不能假定含义不变。替换字符串也有特殊语法。大范围应用前，测试匹配行、不匹配行和近乎空行。

这里填表达式本体，不用斜杠包围，也不在末尾附 gm，标志另填。源码字符串可能还要多一层反斜杠转义。页面有效而代码无效时，要区分正则语法和包裹它的字符串语法。

其他语言或数据库可能使用不同正则方言。这里成功不保证可移植，应检查目标标志、Unicode、语法和替换组引用，再运行相同正反例。

有些表达式在输入稍长时计算量就激增。工具在 Worker 中运行，约一秒截止。超时表示未完成，不代表没有匹配。评估时除短成功例，还要测试较长失败例。

文本和表达式大小受限，匹配列表最多显示 5,000 项。满列表不证明总匹配数就是这些。生产验证或日志汇总仍需自己的限制与失败策略，复制表达式不会带走此工具的超时保护。

订单号式子匹配一例不代表完成。加上前缀、多余后缀、少一位数字等反例。部分匹配用于抽取可能正确，用于验证整行却可能错误。除了数量，还要看高亮范围，区分抽取子串与验证整体。

数字语法也有前提。JavaScript 普通 \d 不会自动把全角１２３当 ASCII 数字。先规范化还是允许其他字符集，应由数据规则决定。忽略大小写标志也不说明 ID 本来就不区分大小写；应让式子符合规则，而非为通过样例放宽规则。

将正例反例一起带入应用测试。JavaScript 式子移到其他引擎时，应复查标志、分组、换行和替换语法。这里一秒内结束不保证任意长度或环境都快，还要测较长的不匹配输入，不能把超时当作合法空结果。