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 更省时间。
