17370845950

^和$锚点确保完整匹配整行或字段值，避免误匹配子串；推荐使用^\\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])$并配合re.fullmatch()与预编译提升准确性和性能。

匹配 YYYY-MM-DD 格式日期时，为什么 ^ 和 $ 很关键

不加锚点容易误匹配到长字符串中的子串，比如 "2025-13-45" 在 "abc2025-13-45def" 中也会被识别。实际业务中多数需要完整匹配整行或字段值。

• 推荐模式：^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])$
• \d{4} 能匹配 0000–9999，如需限制为 1900–2100，改用 (19|20|21)\d{2}
• 月份和日期的分组括号不能省，否则 | 作用域会扩大，导致逻辑错误
• 该正则不校验闰年或大小月，纯格式校验；真实场景建议后续用 datetime.strptime() 做二次解析

匹配带时间的 ISO 8601 格式（如 2025-04-05T14:30:22）

ISO 8601 是最稳妥的时间格式，但常见变体多：有时带毫秒（.123），有时带时区（Z 或 +08:00），直接写死易漏。

• 基础版（无毫秒、无时区）：^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])T([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9]$
• 支持毫秒：\.\d{1,3} 加在秒后，注意转义点号
• 支持 Z 或 ±HH:MM：(Z|[\+\-]\d{2}:\d{2})?，注意 + 在字符组里不用转义
• Python 中用 re.fullmatch() 替代 re.match()，避免开头匹配就返回

用 re.findall() 提取日志里的多个时间戳，结果却少了一半

常见原因是用了贪婪匹配或未处理可选部分，导致正则“吞掉”相邻时间戳之间的分隔符（比如空格、方括号）。

• 日志样例：[2025-04-05 14:30:22] INFO ... [2025-04-05 14:30:25] DEBUG ...
• 错误写法：\[.*?\] → 匹配整个 [...] 块，但无法保证里面是时间
• 正确思路：先定位固定边界（如 \[），再限定内部结构：\[(\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2})\]
• 捕获组 () 再配合 findall() 才能只取时间部分；若用 finditer()，可通过 .group(1) 显式取值
• 注意空格：日志中可能用 \s+ 而非固定空格，避免因缩进或制表符失败

Python 中 re.compile() 预编译是否真有必要

对单次匹配几乎没差别，但在循环中反复调用（如逐行解析上万行日志），预编译能显著减少开销。

• 未预编译：re.search(r'\d{4}-\d{2}-\d{2}', line) 每次都解析正则文本
• 预编译写法：

  date_pattern = re.compile(r'^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])$')
  for line in lines:
      if date_pattern.fullmatch(line.strip()):
          # 处理

• 编译后的对象线程安全，可在多线程中复用
• 调试时打印 date_pattern.pattern 可确认实际使用的正则，避免拼接字符串出错

正则校验日期只是第一步，真正要参与计算或存储，一定得进 datetime 对象；而像 2025-02-30 这种格式合法但语义非法的字符串，正则根本判不出来。