datetime.fromtimestamp() 默认返回无时区信息的本地时间，导致跨时区操作报错；应显式传入tz参数，如tz=timezone.utc或tz=ZoneInfo('Asia/Shanghai')。
datetime.fromtimestamp() 为什么返回错误时区时间？
直接用 datetime.fromtimestamp() 不传 tz 参数时，它默认按本地系统时区解释时间戳，但不会把结果标记为带时区（tzinfo=None）。一旦你后续想用这个时间做跨时区计算或序列化，就会触发 TypeError: can't compare offset-naive and offset-aware datetimes。
常见错误场景：从 API 拿到 Unix 时间戳（如 1717027200），直接转成 datetime 后和 pytz.timezone('Asia/Shanghai').localize(...) 混用，立刻报错。
- 正确做法是显式传入
tz：用datetime.fromtimestamp(1717027200, tz=timezone.utc)得到带 UTC 时区的 datetime - 如果要转本地时区，别依赖系统自动推断，改用
datetime.fromtimestamp(1717027200, tz=ZoneInfo('Asia/Shanghai'))（Python 3.9+） - 旧版本（pytz，但注意
pytz.timezone('Asia/Shanghai').localize(...)只能用于 naive datetime，不能用于已带 tzinfo 的对象
pytz.localize() 和 astimezone() 混用导致偏移错乱
pytz 的 localize() 是给 naive datetime “打上”时区标签，而 astimezone() 是把已有时区的时间转换目标时区。两者语义完全不同，但名字容易让人误以为都能“转换”。
典型错误：对一个已经带 pytz.UTC 的 datetime 再调 .astimezone(pytz.timezone('Asia/Shanghai'))，结果正常；但如果对 naive datetime 直接调 .astimezone()，会静默使用系统本地时区解释，导致时间偏差 8 小时甚至更多（夏令时逻辑也参与计算）。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- naive → 带时区：必须用
tz.localize(naive_dt)，不能用naive_dt.astimezone(tz) - 带时区 → 转其他时区：必须用
aware_dt.astimezone(target_tz)，不能用target_tz.localize(...) - Python 3.9+ 推荐换用
zoneinfo.ZoneInfo，它没有localize()方法，统一用astimezone()，语义更清晰
strftime() 输出时区缩写（如 CST）不可靠
strftime('%Z') 在不同平台、不同 Python 版本下可能输出空字符串、缩写（CST/IST）、甚至错误名称（比如把中国标准时间显示为 “LMT”）。这不是 bug，而是底层 C 库行为不一致。
尤其在 Docker 容器或 Alpine Linux 环境中，%Z 经常失效，%z（+0800）倒基本稳定。如果你需要可读性时区名（如 “China Standard Time”），别依赖格式化，应手动映射：
- 用
dt.tzname()获取当前时区对象的名称（但 pytz 返回的是PST8PDT这类，ZoneInfo 返回Asia/Shanghai） - 真正要显示中文名或标准缩写，建议查表：
{'Asia/Shanghai': 'CST', 'America/New_York': 'EST'} - 避免在日志或 API 响应里用
%Z，优先用 ISO 格式：dt.isoformat()（自动带 +08:00）
datetime.now() 默认不带时区，但很多人误以为它“知道本地时区”
datetime.now() 返回的是 naive datetime，哪怕你在东八区运行，它的 tzinfo 仍是 None。这是历史设计，不是疏忽。
后果很直接：你把它存进数据库（如 SQLAlchemy 的 DateTime 类型），再取出来和带时区的时间比较，立刻 TypeError；或者用它生成 JWT 过期时间，线上服务器时区设为 UTC，本地开发设为 CST，行为就完全不一致。
- 永远显式指定时区：
datetime.now(timezone.utc)或datetime.now(ZoneInfo('Asia/Shanghai')) - Django 用户注意：
timezone.now()是安全的，它等价于datetime.now(timezone.utc)，但原生 datetime 不是 - 如果项目必须兼容旧代码，可在入口加
os.environ['TZ'] = 'Asia/Shanghai'并调time.tzset()，但这只影响time模块，对datetime无效
时区问题最麻烦的地方不在语法，而在“看起来运行正常却埋了坑”——比如测试环境全在 UTC，生产环境混用本地时区，上线后才发现定时任务提前或延后了 8 小时。越早统一用 UTC 存储、显式标注时区，后期越少翻车。
