grep 用 \d+ 筛选行尾编号却匹配不到日志

日志里既有 Patient 432，也有 Patient 123 45566。想筛出只有一个编号、编号后就到行尾的记录，用 grep 'Patient\s\d+\s' 却没有得到预期结果；把最后的 \s 换成 \n 也没解决。

这里同时有两处要调整：默认 grep 的正则方言不等于网页正则测试器，而“数字后还有空白”也不等于“数字已经到行尾”。下面针对 GNU grep，输入是 LF 分行的文本日志，编号限定为 ASCII 数字，字段之间允许空格或制表符。

直接按日志条件写扩展正则

先使用不依赖 PCRE 的写法：

LC_ALL=C grep -E -- 'Patient[[:blank:]]+[0-9]+[[:blank:]]*$' ./test.log

./test.log 替换为待检查的日志副本。这条命令只读取输入，输出完整的匹配行：Patient 后至少一个空格或制表符，接至少一位数字，后面只允许空格或制表符，最后到达行尾。

尾部的 $ 才是行尾锚点。若把它换成另一个必须匹配的空白，就可能选中编号后还有第二个字段的行；仅添加 -P，不能纠正这项逻辑错误。

模式没有在 Patient 前加 ^，因此允许时间、行号等前缀。若业务要求它必须独占整行开头，可加 ^；如果日志中可能出现 OutPatient 等包含该片段的词，还应依据真实字段格式补前置边界，不能把当前示例当成任意日志的通用解析器。

为什么 \d+ 从测试器复制过来会失效

GNU grep 默认使用基本正则表达式。在这种模式下，未转义的 + 不是这里需要的“一次或多次”量词；-E 切换为扩展正则后，才可以直接使用 +。

\d 也不是 GNU grep 基本或扩展正则中受支持的数字简写。不要依赖它恰好被当成字母 d 或其他字符的现象，这类未定义反斜杠写法的行为不应作为脚本约定。选择 -E 时直接用 [0-9]，并通过命令级 LC_ALL=C 固定本例的 ASCII 范围解释。

GNU grep 的基本和扩展正则确实支持 \s 这个空白扩展，不能笼统说所有反斜杠简写都不支持。这里使用 [[:blank:]] 是为了只允许空格和制表符，范围比包含其他空白字符的 \s 更明确。

如果已经确认当前 GNU grep 构建支持 -P，也可以选择 PCRE 模式，但必须同时修正行尾条件：

LC_ALL=C grep -P -- 'Patient[ \t]+[0-9]+[ \t]*$' ./test.log

两种方案按部署环境选一种即可。某些 grep 实现或构建不支持 -P，不必为了这个简单的日志过滤立即更换系统工具；-E 的方案已经能表达所需条件。

用同时包含应选和不应选记录的样本检查

这个短样本不读写业务文件：

printf '%s\n' \
  'line1 Patient 123 45566' \
  'line2 Patient 432' \
  'line3 Patient 234 456' \
  'line4 Patient 321' \
  'line5' |
  LC_ALL=C grep -E -- 'Patient[[:blank:]]+[0-9]+[[:blank:]]*$'

预期只输出：

line2 Patient 432
line4 Patient 321

再补充编号后带空格、带字母、带第二个编号的输入，确认允许和拒绝的边界符合业务。这里允许尾部空白；如果日志约定不允许它们，应去掉尾部的 [[:blank:]]*，而不是保留后声称匹配是严格格式校验。

默认 grep 逐行匹配，普通模式中的 \n 不能代替行尾断言。-z 会把记录分隔改为 NUL，连输入处理方式都变了，不是这项按行筛选的修复开关。

正则正确后仍漏行时，检查输入格式

Windows 风格 CRLF 文本在 Linux 上处理时，行尾可能仍有 CR 字节；它不属于本例允许的空格或制表符，会让数字后到 $ 的条件失败。先确认来源和实际字节，再对保留原件的副本统一换行，不能为了让匹配成功而无条件删掉所有控制字符。

LC_ALL=C 只对当前命令生效，不转换文件编码。本例限定 ASCII 编号，不负责匹配其他文字系统中的数字。若需求包括 Unicode 数字，应先定义数字集合并核对所选引擎的规则。

普通 GNU grep 返回 0 表示选中了行，1 表示没有选中，2 表示错误。脚本应区分“无匹配”和“读取或模式失败”，不能用 || true 把它们统一当成功。保留原过滤命令和日志样本，先检查输出再接入后续流程；若匹配结果会触发删除、更新或告警，回退正则不会自动撤销已经发生的业务动作。