pandas 2.0 重构时间序列底层机制：原生时区支持（嵌入 dtype 层、禁用 pytz）、timedelta 严格类型校验（拒绝 object dtype）、写入时复制（cow）优化链式操作内存占用，并要求显式声明时区与解析日期。
因为 Pandas 2.0 在时间序列处理上不是“加了新功能”，而是重构了底层支撑机制：原生时区支持、Timedelta与Timestamp的深度协同、以及写入时复制（CoW）对链式时间操作的内存保护——这些都不是锦上添花，而是解决旧版本卡顿、OOM、时区转换出错的根本性改动。
原生时区支持不再依赖 pytz 或手动 tz_localize/tz_convert 链
旧版本中，带时区的 DatetimeIndex 实际是“伪时区”：底层仍用 datetime64[ns] 存储 UTC 时间，靠附加元数据模拟时区行为，一不小心就触发 AmbiguousTimeError 或 NonExistentTimeError。Pandas 2.0 把时区信息直接嵌入 datetime64[ns, UTC] 的 dtype 层，.dt.tz_convert() 变成纯位运算，不重建索引、不重排数据。
- 必须用
pd.date_range(..., tz='Asia/Shanghai')直接生成带时区索引，而不是先生成再tz_localize—— 后者在 2.0 中仍可能出错 -
resample('D').mean()在跨夏令时边界时，旧版本会漏掉或重复某小时数据；2.0 默认按本地日历日切分，结果稳定 - 避免混用
pytz和zoneinfo：Pandas 2.0 完全基于zoneinfo，若代码里还显式 importpytz并传给tz参数，会抛TypeError
Timedelta 运算不再隐式升格为 object dtype
旧版本中，df['end'] - df['start'] 如果任意一列是 object 或未正确解析为 datetime64，结果会退化成 object dtype 的 Timedelta 列——无法向量化计算、不能参与 rolling、resample，且内存翻倍。Pandas 2.0 强制要求输入列必须是 datetime64 或 timestamp，否则直接报 TypeError，不静默降级。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 读取 CSV 时务必加
parse_dates=['start', 'end']，别指望pd.to_datetime(df['start'])后再减——后者在 2.0 中若列 dtype 是object，to_datetime返回仍是object，减法失败 -
pd.Timedelta('7 days')和pd.offsets.Day(7)行为不同：前者是固定时长（86400×7 秒），后者是日历偏移（考虑闰秒、夏令时），时间序列对齐必须用后者 -
df['duration'].dt.total_seconds()在 2.0 中返回float64，不是object数组，可直接喂给histogram或groupby().agg('mean')
写入时复制（CoW）让 rolling、resample 链式调用不爆内存
旧版本中，df.resample('H').mean().rolling(24).mean() 会生成两个完整副本：一个用于重采样，一个用于滑动窗口。百万行时间序列轻松吃掉 4GB 内存。Pandas 2.0 默认开启 CoW，上述链式调用只维护引用，直到你执行 df.loc[0, 'value'] = 123 才真正分离内存块。
- 禁用 CoW 会立刻回归旧行为：
pd.options.mode.copy_on_write = False—— 不建议关，除非你明确需要就地修改语义 -
inplace=True参数在 2.0 中已被标记为 deprecated，尤其在resample和rolling中基本失效，它绕不过 CoW 机制 -
rolling窗口大小用24H（字符串）比24（整数）更安全：前者按日历小时对齐（自动跳过缺失时段），后者按行数计数，容易在不规则采样数据中错位
最容易被忽略的点：Pandas 2.0 的时间能力不是“开箱即用”，它依赖你主动约束输入数据类型——datetime64 列不能含 NaT 以外的空值，Timedelta 列不能混入字符串，时区必须统一声明。放任 dtype 推断，反而比 1.x 更容易报错。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
