Python时区问题根源在于各环节时区状态不明确：datetime默认用系统本地时区但不读TZ变量；pandas解析时间默认按系统时区解释；Docker中libc实现影响时区生效；数据库驱动依tzinfo序列化时间；需全程显式指定ZoneInfo统一处理。
Python 中 datetime 读取时间戳后显示错乱，是不是 TZ 环境变量没生效？
不是环境变量没生效，而是 python 大多数时间操作默认走系统本地时区（tzlocal），但不读取 tz 环境变量——除非你显式调用 time.tzset()，且仅在 unix/linux 有效，windows 直接忽略。
-
time.tzset()必须在import time后、任何时间相关函数调用前执行，否则已缓存的时区信息不会刷新 - 即使设置了
TZ=Asia/Shanghai，datetime.fromtimestamp(1717027200)仍可能返回 UTC+8 以外的结果，因为fromtimestamp依赖time.localtime()，而后者受tzset()影响 - 更稳妥的做法是绕过系统时区，直接用
zoneinfo.ZoneInfo（Python 3.9+）或pytz显式指定时区
用 pandas.read_csv() 读取含时间列的文件，为什么解析出来全是 UTC？
因为 pandas 默认把无时区时间字符串当作本地时区处理，但一旦底层 date_parser 或 parse_dates 触发了 dateutil.parser，它会按当前系统时区解释——而某些 Docker 镜像或 CI 环境默认是 UTC，导致“本地”=UTC。
- 显式传入
tz='Asia/Shanghai'不行，read_csv()的tz参数只对已识别为 datetime 的列做转换，不参与解析阶段 - 正确做法：先用
parse_dates读成 naive datetime，再用.dt.tz_localize('Asia/Shanghai')（如果是本地时间）或.dt.tz_convert('Asia/Shanghai')（如果已是带时区时间） - 若原始数据里时间字段明确带时区标识（如
"2024-05-30T10:00:00+08:00"），pandas能自动识别并保留，此时无需手动 localize
docker run 启动容器后，date 命令显示正确，但 Python 脚本里 datetime.now() 还是 UTC
容器内 date 命令读的是系统时区配置（/etc/localtime），而 Python 的 datetime.now() 默认调用 time.localtime()，它是否响应 /etc/localtime 取决于 libc 实现和 Python 版本——glibc 会读，musl（Alpine）基本不认。
- Alpine 镜像必须同时挂载
/etc/localtime和设置TZ环境变量，且在启动命令中加env TZ=Asia/Shanghai - Debian/Ubuntu 镜像只需挂载
/etc/localtime，但 Python 进程需在挂载后启动，否则已加载的时区缓存不会更新 - 最稳方案：不在容器里依赖系统时区，所有时间操作统一用
ZoneInfo("Asia/Shanghai")构造带时区对象，彻底隔离系统影响
数据库写入时间字段时区错乱，是 ORM 自动做了转换吗？
不是 ORM 自动转换，是数据库驱动（比如 psycopg2 或 mysql-connector-python）在发送参数时，把 Python 的 datetime 对象按其 tzinfo 属性决定如何序列化——没 tzinfo 就当本地时间处理，有就转成 UTC 存（PostgreSQL 默认行为）。
-
datetime.now()返回的是 naive 时间，驱动通常按服务器时区解释，容易和应用预期不符 - ORM 如 SQLAlchemy 不会自动补时区，但
DateTime(timezone=True)字段要求传入带tzinfo的对象，否则插入时报错 - 建议统一用
datetime.now(ZoneInfo("Asia/Shanghai"))生成时间，再交给 ORM；若数据库设为 UTC，就在入库前用.astimezone(ZoneInfo("UTC"))转换，而不是依赖驱动猜测
