应始终用 timezone.now() 获取带时区时间，避免 datetime.now()；数据库存取、查询用 utc，仅展示时用 timezone.localtime()；跨月计算用 relativedelta；新项目务必启用 use_tz=true 并配支持时区的数据库。
timezone.now() 返回的是带时区时间，不是 datetime.now()
很多人用 datetime.now() 替代 timezone.now()，结果在生产环境（尤其是开启 USE_TZ = True 时）查不到数据或时间偏移出错。根本原因是：Django 的 ORM 默认只接受带时区的 datetime 对象进行比较，而 datetime.now() 返回的是“本地 naive 时间”，不带 tzinfo。
实操建议：
- 一律用
from django.utils import timezone，调用timezone.now()获取当前带时区时间 - 如果必须从字符串解析，用
timezone.datetime.fromisoformat("2024-06-15T10:30:00+08:00") - 避免用
datetime.strptime(...).replace(tzinfo=...) 手动加时区——容易漏掉夏令时或 DST 切换
timezone.localtime() 不是“转成本地时间”，而是转成 settings.TIME_ZONE 定义的时区
常见错误现象：开发机设 TIME_ZONE = 'Asia/Shanghai'，线上却设成 'UTC'，结果 timezone.localtime() 在两边返回完全不同的小时数，日志/报表时间对不上。
使用场景：仅在需要面向用户展示（比如管理后台、邮件模板）时才用它；数据库存取、条件查询、定时任务逻辑里，应始终用 UTC（即 timezone.now() 原始值）。
实操建议：
- 检查
settings.py中TIME_ZONE和USE_TZ是否匹配：开启USE_TZ后，TIME_ZONE只影响localtime()和模板中的{% now %} - 不要在
filter()或__range查询中传入timezone.localtime()结果——这会导致时区转换两次 - 如需按“用户所在时区”做计算（比如“今天凌晨 0 点”），先用
timezone.localtime()得到该时区的date()，再用make_aware()转回带时区 datetime
跨天/跨月计算别直接加减 days，小心时区和夏令时
比如写 timezone.now() + timedelta(days=30) 看似没问题，但若跨越夏令时切换日（如 3 月 10 日凌晨 2 点跳到 3 点），实际可能多算或少算 1 小时；更糟的是，跨月时 timedelta(days=30) 并不等于“下个月同一天”。
实操建议：
- 需要“下个月第一天”这种语义，请用
dateutil.relativedelta：from dateutil.relativedelta import relativedelta<br>next_month = timezone.now().date() + relativedelta(months=1, day=1)
- 所有涉及“N 天后”“N 小时前”的计算，确认是否要保留原始时区信息——
timezone.now() + timedelta(hours=24)是安全的，但timezone.localtime() + timedelta(hours=24)会丢失时区上下文 - 避免在模型字段默认值里写
default=timezone.now() + timedelta(days=7)——函数调用在模块加载时就执行了，不是每次建实例时动态计算
数据库存储时间字段类型要和 USE_TZ 匹配
PostgreSQL 的 timestamptz、MySQL 的 DATETIME（配合 pytz）、SQLite 的 TEXT 存储方式完全不同。Django 会根据 USE_TZ 自动适配，但一旦配置变更（比如从 False 改为 True），已有数据不会自动迁移，查询结果可能全乱。
实操建议：
- 新项目务必一开始就设
USE_TZ = True，并确保数据库支持时区（PostgreSQL 推荐；MySQL 需确认time_zone设置为+00:00或UTC） - 老项目升级时，先用
python manage.py dbshell检查现有时间字段是否已含时区信息；必要时手动迁移（例如 PostgreSQL 中ALTER COLUMN ... TYPE timestamptz USING column_name AT TIME ZONE 'UTC'） - 不要在
DateTimeField上用auto_now=True——它绕过timezone.now()，直接用 Python 的datetime.now()，在USE_TZ=True下会存成 naive 时间
最常被忽略的一点：Django 的 timezone 工具只解决“表示”和“转换”，不解决“业务时区归属”。比如一个订单创建于 UTC 时间 2024-06-15T16:00:00Z，用户在北京，你得明确“这个订单属于北京时间哪一天”——是按用户注册时区？下单 IP 归属地？还是商户配置的营业时区？这部分逻辑必须自己定义，timezone 模块不会替你猜。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
