Python正则负向后顾匹配异常：非指定时段日志源被误捕获

核心问题1：或运算符|优先级过低，拆分出无约束的独立匹配分支 #

你编写的正则表达式如下：

.+/2020 (?<=12:\d\d:\d\d PM)|(?<=[1-3]:\d\d:\d\d PM) (.+?) \d+

正则语法中|（或逻辑）的优先级是所有运算符里最低的，它会直接把整个表达式切为两个完全独立、互不约束的匹配分支：

• 分支1：.+/2020 (?<=12:\d\d:\d\d PM)，负责匹配中午12点PM的场景，这个分支在当前11PM的测试日志中确实不会命中
• 分支2：(?<=[1-3]:\d\d:\d\d PM) (.+?) \d+，这个分支没有和前面的日期、年份字段做任何绑定，会在整个字符串的所有位置扫描，只要某个位置的左侧文本符合回顾断言规则，就会启动后续的source字段捕获逻辑，这是误匹配的结构基础。

核心问题2：回顾断言未设置小时左边界，被11点的第二位数字绕过 #

你在分支2里使用的零宽正向回顾断言(?<=[1-3]:\d\d:\d\d PM)，逻辑是只检查当前位置的左侧是否存在符合规则的文本片段，不会约束该片段左侧的额外内容；同时你没有给小时数字设置左边界（比如要求小时前必须是空格，是时间字段的起始位），这直接导致11点的时间串被误判为符合规则：
测试日志中的时间串为11:53:41 PM，在PM结束、紧邻后续日志字段的位置，向左截取和断言长度一致的文本，刚好是1:53:41 PM——这里的1是两位数小时11的第二位数字，完全匹配断言里[1-3]的规则，正则引擎会直接判定该位置满足断言要求，向后捕获空格分隔的字段，就拿到了本不该匹配的Microsoft-Windows-DistributedCOM内容。

额外的逻辑漏洞 #

你当前写的时间匹配规则只覆盖了12PM、1-3PM的区间，漏掉了需求里要求的下午4点时段，就算解决了上述误匹配问题，也会漏抓4点整到4点59分的日志。

内容的提问来源于stack exchange，提问作者Rohit Verma