pd.to_datetime() 对混合日期格式报错或返回NaT，因其不自动推断格式且依赖统一格式或显式format参数；应使用dateutil.parser.parse逐行解析或预定义多格式循环尝试。
为什么 pd.to_datetime() 直接报错或转成 NaT
混合日期格式（比如同时存在 "2023-05-12"、"12/05/2023"、"2023年5月12日"、甚至 "2023-05-12 14:30:00"）会让 pd.to_datetime() 默认失败——它不自动猜测格式，遇到第一个无法解析的值就可能抛 ValueError，或设 errors='coerce' 后批量变成 NaT。
根本原因是：Pandas 的解析器依赖统一格式或明确指定的 format 参数，而混合列没有“默认共识”。别指望靠 infer_datetime_format=True 拯救——它只对高度规律的 ISO 格式有效，对中文、斜杠、空格混用完全无效。
- 错误现象：
ValueError: Unknown string format或大量NaT - 典型场景：从 Excel/CSV 导入的用户填写日期、日志文本提取的时间字段、多来源拼接的数据表
- 关键点：
pd.to_datetime()不是万能 OCR，它需要你告诉它“可能有哪些格式”
用 dateutil.parser.parse 逐行柔性解析
当格式不确定且种类多时，放弃批量解析，改用 dateutil.parser.parse 配合 apply() 是最稳妥的 fallback 方案。它能识别上百种常见写法，包括中文年月日、英文缩写、带时区、缺省日/月等。
但注意性能代价：纯 Python 解析比 Pandas 向量化慢 10–100 倍，仅建议用于万级以下数据，或作为清洗阶段的一次性操作。
立即学习“Python免费学习笔记（深入）”；
- 必须加
try/except捕获解析失败，否则整列apply会中断 - 推荐设置
default参数处理缺省时间（如只有日期没时间，可设default=datetime.now().replace(hour=0, minute=0, second=0)） - 示例：
from dateutil import parser<br>import pandas as pd<br><br>def safe_parse_date(x):<br> if pd.isna(x):<br> return pd.NaT<br> try:<br> return parser.parse(str(x))<br> except (ValueError, TypeError):<br> return pd.NaT<br><br>df['parsed_date'] = df['mixed_col'].apply(safe_parse_date)
预定义多格式列表 + pd.to_datetime() 循环尝试
如果格式种类有限（比如已知只有 3–5 种），比逐行解析更快的方法是：列出所有可能的 format 字符串，对每个格式调用 pd.to_datetime(..., errors='coerce')，取首个非 NaT 结果。本质是“向量化试错”，兼顾速度与可控性。
- 格式顺序很重要：把最常见、最严格的格式放前面（如
"%Y-%m-%d"），避免宽松格式（如"%Y/%m/%d"）误匹配其他格式 - 必须用
errors='coerce'，否则任一格式报错就中断 - 避免用
%c或%x这类 locale 相关格式，跨环境易失效 - 常用格式参考：
"%Y-%m-%d"、"%m/%d/%Y"、"%d/%m/%Y"、"%Y年%m月%d日"、"%Y-%m-%d %H:%M:%S"
中文日期要额外处理分隔符和字符
直接传 "2023年5月12日" 给 pd.to_datetime() 会失败，因为默认不识别“年”“月”“日”汉字。有两种解法：
- 用
str.replace()预清洗：先替换汉字为标准符号，再统一解析df['cleaned'] = df['col'].str.replace('年', '-').str.replace('月', '-').str.replace('日', '')，之后走标准pd.to_datetime(..., format="%Y-%m-%d") - 若含“上午/下午”，需先转 24 小时制（如
str.replace('下午', '').str.replace('上午', '')并手动补小时偏移，或交给dateutil.parser处理 - 注意全角/半角符号混用（如“２０２３－０５－１２”），建议清洗时统一用
str.translate()或正则替换
混合日期列没有银弹方案——格式越杂，越得靠人工梳理规律；量越大，越要权衡速度和鲁棒性。别跳过查看前 100 行实际值这步，很多坑都藏在你以为“应该没问题”的那几条异常数据里。
