必须先用pd.to_datetime()转换为datetime64[ns]类型并赋值回列，再用.dt.year/.dt.month提取整数年月；时区列需明确是否转换时区；性能敏感时应缓存.dt访问器或用to_period。
用 .dt.year 和 .dt.month 前必须确保是 datetime 类型
直接对普通字符串或整数列调用 .dt.year 会报 AttributeError: Can only use .dt accessor with datetimelike values。pandas 不会自动推断时间列类型，哪怕列名叫 'date' 或值长得像 '2023-05-12'，它默认还是 object 类型。
- 先用
df['col'].dtype确认类型，不是datetime64[ns]就得转换 - 用
pd.to_datetime(df['col'], errors='coerce')转换，errors='coerce'能把无法解析的值变NaT，避免中断 - 转换后记得赋值回去：
df['col'] = pd.to_datetime(...)，否则后续.dt还是报错
.dt.year 和 .dt.month 返回的是整数，不是字符串
它们返回 int64 类型的纯数字，比如 2023、5，不是 '2023' 或 '05'。如果后续要拼接路径、做分组标签或导出为固定宽度格式，得自己补零或转字符串。
- 补零用
df['col'].dt.month.astype(str).str.zfill(2)，得到'05' - 年月组合推荐用
df['col'].dt.to_period('M')，直接得Period('2023-05', 'M')，天然支持分组和排序 - 别用
strftime('%Y%m')提取字符串再转 int——性能差，且遇到NaT会崩（得先fillna()或用dt.strftime(...).mask(df['col'].isna())）
时区感知列访问 .dt.year 不会报错，但结果可能不符合预期
带时区的 datetime64[ns, UTC] 列，.dt.year 返回的是本地化后的年份（按该时区解释），不是 UTC 时间的年份。比如 2023-01-01 23:00:00+00:00 在北京时间（UTC+8）里是 2023-01-02 07:00:00，.dt.year 仍返回 2023（因为底层按 UTC 存，.dt 访问不自动转换），但如果你先 .dt.tz_convert('Asia/Shanghai') 再取 .dt.year，就变成 2023 对应 1 月 2 日的年份了。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 统一处理建议：先用
.dt.tz_localize(None)去时区（如果业务不依赖时区），再取.dt.year - 保留时区场景下，明确写清楚是“按原始时区解释”还是“转目标时区后解释”，别依赖默认行为
-
.dt.year本身不触发时区转换，这点容易被忽略——它只是从已有的 datetime 值里拆字段
性能敏感场景慎用链式 .dt 访问多次
连续写 df['date'].dt.year、df['date'].dt.month、df['date'].dt.day，pandas 每次都重新构建 DatetimeProperties 对象，小数据不明显，百万行以上会有可观开销。
- 一次性提取多个字段，用
df['date'].dt.to_period('D').dt不行，得改用pd.DataFrame({'year': df['date'].dt.year, 'month': df['date'].dt.month, 'day': df['date'].dt.day}) - 更高效的做法是先缓存
dt_series = df['date'].dt，再写dt_series.year、dt_series.month - 如果只关心年月，
.dt.to_period('M')比分别取 year/month 快，且内存更省
实际用的时候，最常卡住的不是语法，而是忘了检查 dtype 和没处理 NaT ——这两点一漏，后面所有 .dt 操作都白忙。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
