<p>直接用 - 运算符可计算 datetime64[ns] 列的时间差，自动返回 Timedelta；需确保两列类型一致且无时区冲突，避免误用 pd.to_timedelta()，提取数值须用 .dt.days 或 .dt.total_seconds()。</p>
直接用 - 运算符相减，前提是两列都是 datetime64[ns]
只要 df['start'] 和 df['end'] 都是 datetime64[ns] 类型，df['end'] - df['start'] 就会自动返回 Timedelta 列。Pandas 对时间运算做了充分重载，不需要调用额外函数。
- 检查类型：用
df['col'].dtype确认是不是datetime64[ns]，不是就先转：pd.to_datetime(df['col']) - 常见错误现象：结果是
object类型、值为NaT或一堆字符串（如'1 days 02:30:00'），基本就是其中一列没转成功 - 注意时区：如果一列带时区（如
UTC）、另一列不带，相减会报TypeError: DatetimeArray subtraction must have the same timezones
pd.to_timedelta() 不是用来“转换时间差”的，别乱用
pd.to_timedelta() 的作用是把字符串、数字、np.timedelta64 等转成 Timedelta，不是用来处理两个时间列相减的中间步骤。误用它反而容易绕进坑里。
- 错误写法：
pd.to_timedelta(df['end'] - df['start'])—— 这步多余，而且如果输入已经是Timedelta，它会尝试二次解析，可能出错或变慢 - 正确场景举例：你有一列存的是“小时数”（
float），想转成Timedelta，才用pd.to_timedelta(df['hours'], unit='h') - 性能影响：对已有的
Timedelta列再套一层to_timedelta，会触发冗余解析，小数据看不出来，大数据明显拖慢
结果为 NaT 的三个高频原因
相减后出现大量 NaT，不是计算失败，而是输入本身有问题。重点排查这三项：
-
NaN或空字符串混在原始时间列里：用pd.to_datetime(..., errors='coerce')转换时，非法值会变NaT，后续相减仍得NaT - 两列长度不一致（比如用了
shift()但没对齐）：Pandas 会按索引对齐，索引错位就会导致大量NaT - 其中一列是
object类型但内容其实是时间字符串，且格式不统一（如混着'2023-01-01'和'01/01/2023'）：pd.to_datetime默认只猜一种格式，遇到第二种就崩成NaT
提取天数、秒数等数值要用 .dt.days、.dt.total_seconds()
得到 Timedelta 列后，不能直接用 .values 或 int() 强转——那会拿到 numpy.timedelta64 对象，行为不可控。必须走 .dt 访问器。
立即学习“Python免费学习笔记（深入）”；
-
td_col.dt.days：返回整数天数（Timedelta('3 days 5:30:00')→3） -
td_col.dt.total_seconds()：返回总秒数（3 * 86400 + 5*3600 + 30*60 = 279000.0） - 别用
.dt.seconds：它只返回“不足一天的秒数”，即5*3600 + 30*60 = 19800，容易漏掉天数部分 - 兼容性注意：
.dt.total_seconds()在旧版 Pandas（NaT 返回nan，新版返回NaT；若需统一数值型输出，建议先fillna(pd.Timedelta(0))
时间差看着简单，但类型隐式转换和 NaT 传播特别容易悄无声息地污染结果。最稳妥的做法永远是：先确认两列 dtype，再相减，最后用 .dt 提取你需要的粒度——中间跳任何一步，都可能让后续分析跑偏。
