fuzzy=true 会放弃校验、强行凑出“合理”时间而非报错，导致月份/日期溢出被修正、非日期字符串也被解析；仅适用于明确接受误判的弱输入源，且性能差、与default冲突；应优先用strptime+异常捕获或预清洗后谨慎使用。
parse() 的 fuzzy=True 会让日期解析“睁一只眼闭一只眼”
它不是增强容错，而是放弃校验——遇到模糊字段（比如把“Jan”当成“January”、把“2023/13/01”里的13月当成1月）时，dateutil.parser.parse 会强行凑出一个“看起来合理”的 datetime，而不是报错。
常见错误现象：parse("2023-13-01") 返回 datetime(2023, 1, 1)；parse("2023-01-32") 返回 datetime(2023, 2, 1)；甚至 parse("abc 2023 def") 也能返回 datetime(2023, 1, 1)。
- 仅在明确接受“弱输入源”且业务允许误判时启用，例如日志中混杂的非结构化时间片段
-
fuzzy=True会显著拖慢解析速度，因为要尝试多种字段匹配组合 - 与
default参数叠加使用时更危险：默认值会被悄悄覆盖或补全，比如parse("Jan", default=datetime(2020,6,15))在 fuzzy 模式下可能返回2020-01-15而非你预期的2020-01-01
替代方案：用 strptime() + 异常捕获更可控
如果你知道输入格式大概率是某几种（如 "%Y-%m-%d"、"%d/%m/%Y"），硬编码尝试比交给 fuzzy 更可靠。
示例逻辑：
立即学习“Python免费学习笔记（深入）”；
from datetime import datetime formats = ["%Y-%m-%d", "%d/%m/%Y", "%Y/%m/%d"] for fmt in formats: try: return datetime.strptime(date_str, fmt) except ValueError: continue raise ValueError(f"无法解析日期: {date_str}")- 每个
fmt都是明确契约，不猜、不妥协 - 性能比
fuzzy=True高一个数量级，尤其在格式较固定时 - 注意
%y（两位年份）和%Y（四位）的区别，用错会导致 1923 → 2023 这类跨世纪偏移
需要 fuzzy？先做预清洗再 parse
真正难处理的不是“模糊”，而是“脏”——比如 “2023年13月1日”、“2023-01-32Txx:xx:xx”、“[DATE]2023/1/1[/DATE]”。这时候 fuzzy=True 是最后一道兜底，不是第一道入口。
- 用正则提前剥离无关字符：
re.sub(r"[^d/-.年月日s]", "", s) - 对常见中文别名做映射：“一月”→“01”，“廿三”不处理（直接拒掉），避免引入语义歧义
- 长度过滤：少于6位或大于12位的字符串直接跳过
parse，防止把 “ID:12345” 当成日期 - 如果清洗后仍需 fuzzy，务必加
settings={'STRICT': True}（dateutil>=2.8.2），它能禁用部分最激进的自动修正（如月份溢出）
测试时最容易漏掉的边界：时区和午夜偏移
fuzzy=True 对含时区的字符串（如 "2023-01-01 UTC"）处理不稳定，有时吞掉时区，有时又强行绑定本地时区；更隐蔽的是，它可能把没有时间部分的输入（如 "2023-01-01"）按系统本地时区解释为 2023-01-01 00:00:00+08:00，而你实际想要的是 naive 的 2023-01-01。
- 显式传入
tzinfos参数控制时区识别，不要依赖自动推断 - 解析后立刻检查
.tzinfo是否为None，不是就用.replace(tzinfo=None)或.astimezone(timezone.utc)显式归一化 - 对纯日期场景，优先用
dateutil.parser.parse(...).date()，但注意这会丢失原始时区上下文，得看业务是否允许
真正麻烦的从来不是“能不能解析”，而是“解析出来的那个时间，到底代表什么”。fuzzy 模式下，这个“代表什么”往往由 parser 内部启发式规则决定，而不是你的代码逻辑。