^和$锚点确保完整匹配整行或字段值，避免误匹配子串；推荐使用^\\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])$并配合re.fullmatch()与预编译提升准确性和性能。
匹配 YYYY-MM-DD 格式日期时，为什么 ^ 和 $ 很关键
不加锚点容易误匹配到长字符串中的子串，比如 "2023-13-45" 在 "abc2023-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 格式（如 2023-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() 提取日志里的多个时间戳，结果却少了一半
常见原因是用了贪婪匹配或未处理可选部分，导致正则“吞掉”相邻时间戳之间的分隔符（比如空格、方括号）。
- 日志样例：
[2023-04-05 14:30:22] INFO ... [2023-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() 预编译是否真有必要
对单次匹配几乎没差别，但在循环中反复调用（如逐行解析上万行日志），预编译能显著减少开销。
立即学习“Python免费学习笔记（深入）”；
- 未预编译：
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 对象；而像 2023-02-30 这种格式合法但语义非法的字符串，正则根本判不出来。
