ZoneInfo 是 Python 标准库原生时区实现，比 pytz 更可靠轻量，与 Django 4.0+ 深度对齐；必须直接用 ZoneInfo 初始化 datetime，禁用 replace(tzinfo=) 赋时区，跨时区转换唯一合法方式是 astimezone()。
因为 ZoneInfo 是 Python 标准库原生支持的时区实现，它比 pytz 更可靠、更轻量，且与 Django 4.0+ 的时区机制深度对齐——不改用它，迟早会遇到隐式转换错误或升级阻塞。
ZoneInfo 构造时间必须一步到位，不能 replace(tzinfo=)
很多老代码习惯先创建“天真时间”，再用 replace(tzinfo=...) 强行赋时区。这在 ZoneInfo 下是危险操作：它不校验该时间在目标时区是否真实存在（比如夏令时跳变时刻），也不做任何偏移换算，只是把数值“硬贴”上一个时区标签。
- ✅ 正确做法：直接用
ZoneInfo初始化datetime - ❌ 错误做法：用
replace(tzinfo=ZoneInfo("Asia/Shanghai"))给无时区时间“打补丁” - ⚠️ 特别注意：
astimezone()才是跨时区转换的唯一合法方式；replace()只适用于“明确赋予原始含义”，比如解析一个已知属于上海的 ISO 字符串但没带偏移
Django 4.0+ 中 timezone.now() 返回的是 ZoneInfo-aware 时间
启用 USE_TZ=True 后，django.utils.timezone.now() 返回的已经是绑定 ZoneInfo 实例的感知时间，其 tzinfo 类型是 zoneinfo.ZoneInfo，不是 pytz.BaseTzInfo。如果你手动构造时间并传给 DateTimeField，类型不匹配可能触发静默截断或时区错位。
Django Unfold
下载
提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。
- 检查方法：打印
timezone.now().tzinfo，确认是ZoneInfo实例而非FixedOffset或pytz对象 - 数据库写入前务必确保所有时间对象都使用
ZoneInfo，尤其从外部 API 接收字符串时，优先用datetime.fromisoformat()+ 显式replace(tzinfo=...)，而不是strptime加时区名（strptime不支持 IANA 时区名） - 模板中显示时间时，Django 会自动调用
astimezone()转为目标用户时区——前提是输入是ZoneInfo-aware 时间；否则可能 fallback 到系统本地时区，结果不可控
pytz 的 localize() 和 normalize() 在 ZoneInfo 中没有等价物
pytz 的 localize() 是为“天真时间”安全绑定时区而设计的，normalize() 用于修正跨夏令时边界后的偏移。这两个方法在 ZoneInfo 中根本不存在——因为 ZoneInfo 要求你从一开始就构造带时区的时间，避免中间态歧义。
立即学习“Python免费学习笔记（深入）”；
- 迁移时必须重写所有含
pytz.timezone(...).localize(...)的逻辑，改为直接用datetime(..., tzinfo=ZoneInfo(...)) - 如果项目还在用
USE_DEPRECATED_PYTZ=True过渡，这只是延缓问题，不是解决方案；Django 5.0 会彻底移除pytz支持 -
pytz_deprecation_shim包能帮你检测残留调用，但它只是诊断工具，不能替代重构
真正难的不是语法替换，而是厘清“这个时间值究竟代表什么物理时刻”。用 ZoneInfo 后，所有时间必须携带明确的时区语义，不能再靠上下文猜测——这是它比 pytz 严格的地方，也是它更少出错的原因。
