datetime.now() 不带时区是危险起点，应始终显式指定时区如 zoneinfo("asia/shanghai")；避免 pytz 与 zoneinfo 混用、硬编码 utc+8 偏移，数据库存 utc 时间并按需转换显示。
datetime.now() 不带时区就是危险的起点
Python 的 datetime.now() 默认返回“本地时间 + naive datetime”，也就是没有时区信息的时间对象。它看起来正常，但一旦参与跨时区计算、序列化或存入数据库，就可能错位一小时甚至一天。
常见错误现象：datetime.now().isoformat() 输出 "2024-05-12T14:30:00"，但你不知道这是北京时间、东八区、还是系统当前任意时区；后续用 astimezone() 转换时抛出 ValueError: astimezone() cannot be applied to a naive datetime。
实操建议：
- 永远用
datetime.now(tz=zone)显式指定时区，例如datetime.now(tz=ZoneInfo("Asia/Shanghai")) - 避免用
time.timezone或time.tzname推断本地时区——它们不处理夏令时，也不反映系统真实配置 - 如果必须从 naive datetime 补时区，用
.replace(tzinfo=...)而非.astimezone()，但仅限你 100% 确认该时间本就属于那个时区
pytz 与 zoneinfo 混用会触发静默错误
pytz 的 timezone("Asia/Shanghai") 返回的是一个“可调用对象”，而 zoneinfo.ZoneInfo("Asia/Shanghai") 是标准时区类型。两者混用不会报错，但 astimezone() 行为异常：比如把 pytz 时区传给 zoneinfo 时间对象，结果时间值不变、时区名却乱了。
立即学习“Python免费学习笔记（深入）”；
使用场景：旧项目用 pytz，新代码想切 zoneinfo（Python 3.9+ 内置），中间过渡期最容易踩坑。
实操建议：
- 全项目统一时区类型：Python 3.9+ 优先用
ZoneInfo，别再引入pytz - 若需兼容旧
pytz对象，先用dt.astimezone(pytz.UTC).replace(tzinfo=None)剥离时区，再用ZoneInfo重建 -
pytz的localize()和normalize()在zoneinfo下不存在，不要试图“翻译”调用逻辑
Asia/Shanghai ≠ UTC+8 的硬编码偏移
把北京时间当成固定 UTC+8 偏移来加减，是初学者最常写的 Bug。实际上中国虽不实行夏令时，但 ZoneInfo("Asia/Shanghai") 仍通过 IANA 时区数据库维护历史变更（如 1949 年前上海用 GMT+8:06，1992 年曾短暂调整过）；更重要的是，硬编码 +8 会让代码在解析历史时间（如 1986–1991 年夏令时期间的中国大陆）时完全失效。
性能影响：硬编码偏移看似快，但失去时区语义后，fromtimestamp()、strptime() 等操作无法正确回溯 DST 边界，反而导致运行时逻辑错误，调试成本远高于毫秒级性能损耗。
实操建议：
- 所有时区引用必须用字符串名，如
ZoneInfo("Asia/Shanghai")，而非timedelta(hours=8) - 读取用户输入的“北京时间”字符串时，用
datetime.fromisoformat(s).replace(tzinfo=ZoneInfo("Asia/Shanghai"))，而不是先转成 timestamp 再加 8 小时 - 数据库字段存 UTC 时间（
tz=ZoneInfo("UTC")），显示时再转本地时区——这样既规避本地时钟漂移，也避免历史偏移误判
strftime("%Z") 和 %z 在不同时区对象下输出不稳定
%Z 输出时区缩写（如 CST），%z 输出 ±HHMM 偏移（如 +0800）。但它们的行为高度依赖底层时区对象实现：ZoneInfo 在某些旧系统上可能返回空字符串，pytz 则对夏令时缩写处理不一致（比如把 Asia/Shanghai 错标为 CST，而 CST 实际指美国中部时间）。
使用场景：日志打点、API 响应、文件名生成等需要“可读时区标识”的地方。
实操建议：
- 对外暴露时间字符串时，优先用 ISO 8601 格式（
dt.isoformat()），它自带完整时区信息且无歧义 - 必须用
%Z或%z时，先确保 dt 是ZoneInfo时区对象，并测试边界时间点（如 1991-09-15 02:00:00，夏令时结束时刻） - 别依赖
%Z做逻辑判断——缩写不可靠，"CST"可能是 China Standard Time，也可能是 Central Standard Time
