后端应使用带时区的 datetime（如 datetime.now(timezone.utc)）存时间，前端解析 ISO 格式字符串（含 Z 或 +00:00）才能正确显示 UTC 时间，避免 naive datetime 导致的 8 小时偏差。
后端用 datetime.utcnow() 存时间，前端显示总差8小时？
不是时区没传，是后端存的压根没带时区信息。Python 的 datetime.utcnow() 返回的是 naive datetime（无时区），数据库里存的只是“某个 UTC 时刻的数值”，但系统不认它是 UTC —— 它连 tzone 属性都没有。前端 JS 的 new Date('2024-05-10 12:00:00') 会按本地时区解析这个字符串，结果就是：你存的是“UTC中午”，它当成了“本地中午”再转成 UTC 渲染，自然偏移。
- 永远别用
datetime.utcnow()或datetime.now()直接入库；改用datetime.now(timezone.utc)（Python 3.6+）或pytz.UTC.localize(datetime.utcnow()) - 存进数据库前，确保
dt.tzinfo is not None，且dt.isoformat()输出带Z或+00:00 - Django 用户注意：
USE_TZ = True且字段用DateTimeField，否则 ORM 会静默剥离时区
前端 new Date() 解析 ISO 字符串失败或偏移？
后端返回 "2024-05-10 12:00:00" 这种没时区标识的字符串，JS 会按本地时区解释。哪怕你后端本意是 UTC，只要没写 Z 或 +00:00，前端就无从得知。
- 后端序列化必须用
dt.isoformat()（不是str(dt)），它对带时区的datetime自动输出"2024-05-10T12:00:00+00:00"或"2024-05-10T12:00:00Z" - 避免手动拼接字符串，比如
f"{dt.year}-{dt.month}..."—— 丢时区、少补零、还可能错格式 - FastAPI 用户检查
pydantic.BaseModel是否用了datetime类型字段（自动调用isoformat），而不是str字段
为什么用 datetime.fromtimestamp() 渲染时间总出错？
后端传来的 Unix timestamp 是秒数，但它代表的是“UTC 时间戳”。而 datetime.fromtimestamp(ts) 默认按系统本地时区解释，相当于做了两次本地化：一次在服务端生成 timestamp（UTC → 本地秒数），一次在前端又转回本地时间，结果翻倍偏移。
- 前端该用
new Date(ts * 1000)（JS timestamp 是毫秒），它天然按 UTC 解释 timestamp - Python 后端生成 timestamp 时，务必用
dt.timestamp()（要求dt带时区），别用time.time()硬凑 - 如果必须用
fromtimestamp，得显式传时区：datetime.fromtimestamp(ts, tz=timezone.utc)，但没必要 —— 直接用utcfromtimestamp更安全
数据库字段类型选 timestamp without time zone 还是 with time zone？
PostgreSQL 的 timestamp with time zone（timestamptz）不是存时区，而是把输入时间立刻转成 UTC 存储，并在读取时按客户端时区转出 —— 这个“自动转换”在 Web API 场景下是干扰项。你后端 Python 已经做了时区归一化，再让 PG 多转一次，容易和 ORM 行为冲突。
立即学习“Python免费学习笔记（深入）”；
- PostgreSQL：统一用
timestamptz，但确保所有写入都带明确时区（如2024-05-10 12:00:00+00:00），并关掉连接级SET timezone - MySQL：没有真正带时区类型，
DATETIME是 naive，TIMESTAMP存的是 UTC 但会自动转——推荐全栈统一用TIMESTAMP+ 后端强制 UTC 写入 - SQLite：无时区支持，靠应用层保证存的是 UTC 字符串（ISO 格式）或整数 timestamp
最麻烦的不是存，是跨语言时区库行为不一致：Python pytz 和 zoneinfo 对夏令时处理不同，JS Intl.DateTimeFormat 又依赖运行环境时区数据。别指望“自动对齐”，每个环节都得显式声明意图。
