to_datetime(errors='coerce')能“救”乱时间字符串是因为它遇错不报，统一转为nat保流程不断；但nat是缺失值需后续处理，且须配合strip、replace、format等预处理与验证。

to_datetime(errors='coerce') 为什么能“救”乱七八糟的时间字符串

它不是修复，是“保命式转换”：遇到无法解析的值（比如 "2023-13-01"、"???"、None），不报错，统一转成 NaT（Not a Time），让后续操作不至于中断。但你要清楚——NaT 是缺失值，不是合法时间，后续做计算或分组前必须处理。

常见错误现象：ValueError: month must be in 1..12 或 OutOfBoundsDatetime 直接崩掉；或者没加 errors='coerce'，结果只有一行错，整列转换失败。

• errors='ignore' 看似温和，实则危险：原样保留非法字符串，后续调用 .dt.day 会报 AttributeError
• errors='raise'（默认）适合调试期，不适合生产数据清洗
• 如果原始列含数字（如 20230101），to_datetime 默认按整数解释为纳秒时间戳，得加 unit='D' 或显式 format

转换后怎么快速识别并剔除 NaT 行

别用 df.dropna(subset=['date_col']) 就完事——它只删 NaT，但你可能还混着空字符串、全空格、"NULL" 这类“伪缺失”。得先归一化再筛。

• 转换前建议先 df['date_col'] = df['date_col'].str.strip()，干掉首尾空格
• 对明显非法值（如 "--"、"0000-00-00"）可提前 .replace() 成 np.nan，再进 to_datetime
• 转换后检查：df['date_col'].isna().sum() 看多少 NaT；用 df.loc[df['date_col'].isna(), 'date_col'].unique() 反查原始脏数据长啥样
• 剔除时推荐 df = df.dropna(subset=['date_col']).copy()，加 .copy() 避免 SettingWithCopyWarning

format 参数比 errors 更早决定成败

如果你知道原始格式高度一致（比如全是 "YYYY/MM/DD HH:MM"），强制指定 format 不仅快 3–5 倍，还能避免歧义（比如 "01/02/03" 到底是 2001 年 2 月 3 日，还是 2003 年 1 月 2 日？）。

• 常用 format 示例：format='%Y-%m-%d %H:%M:%S'、format='%d/%m/%Y'、format='%Y%m%d'
• 含毫秒用 %f，注意位数；年份两位用 %y，四位用 %Y
• 一旦 format 写错（比如把 %Y 写成 %y 解析 2023），会静默出错（返回错误日期），而不是报错——所以务必抽样验证结果
• 不确定格式时，别硬猜，先用 errors='coerce' 跑通，再挑几条典型值手动试 pd.to_datetime("xxx", format=...)

时区和精度问题常被忽略

没声明时区的时间，在跨系统或存数据库时可能被自动补成本地时区，导致比较错乱；而 datetime64[ns] 默认纳秒精度，但很多业务只需天级，浪费内存还影响 groupby 性能。

• 若原始数据无时区（如 "2023-01-01"），转换后仍是 naive datetime；需时区请追加 .dt.tz_localize('UTC') 或 .dt.tz_convert('Asia/Shanghai')
• 只要日期不要时间，转完立刻 .dt.date（转成 Python date 对象）或 .dt.floor('D')（保持 datetime64 类型但归零时分秒）
• 内存敏感场景：用 df['date_col'] = pd.to_datetime(...).astype('datetime64[D]') 降为天级精度，内存可省 75%
• 注意：datetime64[D] 不能直接算时差（.diff() 会变 timedelta64[D]），但多数聚合够用

真正麻烦的从来不是 to_datetime 本身，而是你不知道原始数据里藏着多少种“看起来像时间”的字符串——多跑一次 value_counts().head(20)，比硬写 format 更省时间。