因为 datetime.now() 返回本地时区的 naive 时间，而 Django 开启 USE_TZ=True 后期望 aware 时间，混用导致 UTC 误存引发 +8 小时偏差；应统一用 timezone.now()、make_aware() 和 Asia/Shanghai 时区配置。
为什么 datetime.now() 和数据库存的时间总是差8小时？
因为 datetime.now() 返回的是本地时区（如系统设为 CST）的 naive datetime，而 Django 默认开启时区支持（USE_TZ = True）后，所有模型字段（如 DateTimeField）期望接收的是带时区的 aware datetime。两者混用就会导致入库时间被错误解释——比如把 14:00 当成 UTC 存进去，查出来就变成 22:00（+8 小时），实际却显示为次日。
解决思路不是关掉时区，而是统一使用 aware 时间：
- 永远不用
datetime.now()或datetime.today()，改用django.utils.timezone.now() - 如果必须从字符串解析，用
django.utils.timezone.make_aware()（配合明确指定pytz.timezone('Asia/Shanghai')），而不是replace(tzinfo=...) - 检查
settings.py中TIME_ZONE设为'Asia/Shanghai'，且USE_TZ = True（推荐保持开启）
数据库里时间是对的，但模板中 {{ obj.created_at }} 显示错乱？
Django 模板默认将 aware datetime 转换为 TIME_ZONE 对应的本地时间展示。但如果模型字段本身是 naive 的（比如旧数据或手动赋值未带时区），Django 会按 TIME_ZONE 强行“解释”它，造成偏差。
验证方法：在 shell 中打印 obj.created_at.tzinfo，返回 None 就是 naive；返回 UTC 或 Asia/Shanghai 才是 safe 的。
立即学习“Python免费学习笔记（深入）”；
- 迁移旧数据时，用
make_aware(dt, pytz.timezone('Asia/Shanghai'))批量修正 - 避免在视图里写
obj.created_at.replace(tzinfo=...)—— 它不处理夏令时，且和pytz行为不一致 - 模板中可显式控制时区：
{{ obj.created_at|timezone:"Asia/Shanghai" }}，但前提是原值已是 aware
filter(created_at__date=today) 查不到今天的数据？
这是最隐蔽的坑：__date 查询会把数据库中存储的 UTC 时间转成 TIME_ZONE 时区再截日期。如果数据库存的是 UTC，而你传入的 today 是本地时间（比如 date.today()），那范围就错位了。
正确做法是让两边都基于同一时区计算：
- 用
timezone.now().date()代替date.today() - 更稳妥的是用范围查询：
filter(created_at__gte=timezone.now().date(), created_at__lt=timezone.now().date() + timedelta(days=1)) - 注意 PostgreSQL 的
AT TIME ZONE行为：Django 自动处理，但自定义 SQL 中必须显式转换时区
用 Pandas 处理 Django QuerySet 时间字段时区报错？
Pandas 默认把 datetime 当作 naive 处理，遇到 Django 返回的 aware datetime 会抛 ValueError: Tz-aware datetime.datetime cannot be converted to datetime64 unless utc=True。
别调 dt.tz_localize(None) 硬砍时区——这会丢失信息。应该：
- 转成 UTC 再进 Pandas：
pd.Series([dt.astimezone(pytz.UTC) for dt in qs.values_list('created_at', flat=True)]) - 或用
pd.to_datetime(..., utc=True)并确保输入是 ISO 格式字符串（Django model 的isoformat()输出带时区） - 导出 CSV 前统一转本地时间：
dt.astimezone(pytz.timezone('Asia/Shanghai')).strftime('%Y-%m-%d %H:%M:%S')
时区问题本质是「解释权」归属问题：谁负责把时间戳读成人类可读的时刻？Django 要求你在输入阶段就明确时区，而不是靠 guess。一旦中间环节出现 naive datetime，偏差就不可逆。
