pd.Timedelta是纯时间长度，不涉及时区与日历逻辑，加减需作用于Timestamp或datetime类型，不可直接用于str或date；与datetime.timedelta可混用但存在隐式转换陷阱。
为什么 pd.Timedelta 加减后结果不是你预期的日期？
因为 pd.Timedelta 本身不带时区、不绑定日历逻辑，它只是纯粹的“时间长度”——比如 pd.Timedelta('30D') 就是精确的 30 × 24 × 3600 秒，不会自动避开周末或节假日。如果你拿它直接加到 datetime.date 或字符串上，Pandas 会尝试转换但可能静默失败或返回 NaT。
- 必须确保左操作数是
pd.Timestamp或pd.Series/DataFrame中的 datetime 类型列（用pd.to_datetime()显式转） - 别对
str类型列直接做+ pd.Timedelta(...)，会报TypeError: unsupported operand type(s) for +: 'str' and 'Timedelta' - 用
df['date'].dt.dayofweek配合np.where才能实现“跳过周末”的业务逻辑，Timedelta自己做不到
pd.Timedelta 和 datetime.timedelta 能混用吗？
能，但有隐式转换陷阱。Pandas 在多数场景下会把 datetime.timedelta 自动转成 pd.Timedelta，但反过来不行——比如传给 resample('30T') 这类原生 Pandas 方法时，若误传 datetime.timedelta(minutes=30)，部分旧版本（ValueError: Invalid frequency。
- 统一用
pd.Timedelta('30T')或pd.Timedelta(minutes=30)，避免跨库混用 -
pd.Timedelta支持更多单位缩写：比如'30S'、'2H'、'5D'、'1W'；而datetime.timedelta只认days/seconds/microseconds关键字参数 - 性能上无差别，但
pd.Timedelta在Series.dt操作中更稳定，尤其涉及纳秒精度时
处理“月末最后一天”偏移时，为什么不能只靠 pd.Timedelta？
因为 pd.Timedelta 是固定长度，而“月末”是日历概念。比如 2023-01-31 + pd.Timedelta('30D') = 2023-03-02，不是 2023-02-28；它不会帮你对齐到目标月的最后一天。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 要用
pd.offsets.MonthEnd()或pd.offsets.DateOffset(months=1)替代 -
pd.offsets.MonthEnd(n=1)表示“移到下一个自然月末”，n=0表示“移到当前月末” - 混合使用时注意顺序：
ts + pd.offsets.MonthEnd() + pd.Timedelta('2D')先对齐月末再加两天；反过来就可能跨月失效
在 groupby().apply() 中动态生成 Timedelta 容易出什么错？
常见错误是把标量计算结果（如 row['days'] * 24 * 3600）直接塞进 pd.Timedelta 构造器，却忘了 Pandas 对 int 默认按纳秒处理——结果偏移小得看不见。
立即学习“Python免费学习笔记（深入）”；
- 显式指定单位：
pd.Timedelta(row['days'], unit='D')，而不是pd.Timedelta(row['days']) - 如果
row['days']是浮点数（比如 1.5 天），用unit='D'没问题；但用unit='s'就必须取整，否则报ValueError: cannot construct a Timedelta from a float with unit='s' - 批量构造更快的方式是：
pd.to_timedelta(df['days'], unit='D')，比逐行apply高效一个数量级
真正麻烦的是嵌套偏移逻辑：比如“每个用户按其注册天数×1.2再向上取整到最近小时”，这种得先算数值再喂给 pd.Timedelta，中间少一步类型/单位校验，NaT 就悄无声息地进结果了。
