pd.to_datetime()报错或返回nat主因是输入含空值、不规范格式（如"2023/13/01"）或时区缺失；默认静默转nat易致数据丢失，应先用errors="coerce"定位问题，再结合format参数精准解析或dateutil.parser兜底。
为什么 pd.to_datetime() 直接报错或变 NaT
常见原因是字符串里混了空值、不规范格式（如 "2023/13/01"、"--"、"unknown"）或时区信息缺失。默认下 pd.to_datetime() 遇到无法解析的值会直接转成 NaT，且不报错——你可能根本没意识到数据已“静默丢失”。
实操建议：
python-docx
下载
python-docx Skill功能概述python-docx Skill是一项面向实际任务的技能，主要用于本Skill提供使用python-docx生成专业Word文档的标准方法和最佳实践；生成安全服务方案文档；核心要点生成技术架构设计文档；生成任何需要专业排版的Word文档；核心库 : python-docx；使用与执行辅助库 : docx.shared , docx.enum , docx.oxml.ns；标准代码模板；1. 文档初始化；2. 字体设置（必须！它将相关步骤、工具调用和结果整理方式集
- 先用
df["col"].sample(10)和df["col"].str.len().value_counts().head()快速看分布，揪出异常长度或明显非法值 - 加参数
errors="coerce"是安全底线，但要配合后续检查：df["col"].isna().sum() - 若确认数据干净，可加
errors="raise"强制暴露问题，比事后排查强得多
怎样指定格式让转换快 3–5 倍
不指定 format 参数时，pd.to_datetime() 会逐个字符串尝试多种解析路径，开销大。一旦你知道格式统一（比如全是 "%Y-%m-%d %H:%M:%S"），硬编码格式能跳过推断逻辑。
实操建议：
- 用
df["col"].str[:19].nunique()粗略验证前 19 位是否高度一致（覆盖常见时间戳长度） - 格式字符串必须严格匹配，
"%Y/%m/%d"解析不了"2023-01-01"；注意年份是%Y（4 位）还是%y（2 位） - 含毫秒时用
%f，但注意它只吃 6 位数字；"2023-01-01 12:00:00.123"要写成"%Y-%m-%d %H:%M:%S.%f"，否则截断或报错
处理带时区的字符串（如 "2023-01-01T12:00:00Z"）
默认 pd.to_datetime() 解析后是 naive datetime（无时区信息）。若原始字符串含 Z、+0800 或 UTC，需显式处理，否则后续时区转换会出错。
实操建议：
- 优先用
utc=True：它会把Z、+0000等自动转为 UTC-aware datetime，且性能好于先转再.dt.tz_localize() - 若字符串含本地时区偏移（如
"+0800"），utc=True仍可用，结果是 UTC 时间；需要保留本地时区语义？改用infer_timezone=True+origin="local"组合 - 避免用
.dt.tz_localize("Asia/Shanghai")直接套在 naive 时间上——这假设所有时间都属该时区，但实际可能是 UTC 字符串被误标
内存和 dtype 陷阱：为什么转完反而更占内存
datetime64[ns] 列理论上比 object 列省空间，但如果列里存在大量 NaT，Pandas 会退化为 object dtype（尤其在旧版本或混合类型场景），导致内存翻倍。
实操建议：
- 转换后立刻检查：
df["col"].dtype—— 正常应为datetime64[ns]，不是object - 若有
NaT且数量可控，考虑用fillna(pd.Timestamp("1970-01-01"))占位（慎用于计算），或分块处理降低峰值内存 - 读 CSV 时就预防：用
parse_dates=["col"]+date_parser（配合lambda x: pd.to_datetime(x, format=...)）比读完再转更省内存
NaT 在某次 groupby 后突然让整个结果变空——这些得靠转换前后主动查样本和 dtype，而不是等报错。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
