time.localtime() 返回本地时区时间但无时区信息，依赖系统设置导致跨平台时间偏差；应使用 datetime.now(zoneinfo.ZoneInfo("Asia/Shanghai")) 显式指定时区生成准确时间戳。
time.localtime() 返回的是本地时区时间，但没显式声明时区
很多爬虫用 time.strftime("%Y-%m-%d %H:%M:%S", time.localtime()) 记录请求时间，结果发现和北京时间差8小时、或差整数小时——根本原因不是代码写错，而是 time.localtime() 依赖系统当前时区设置，而 Python 的 time 模块本身不带时区信息（tzinfo=None）。它只是把系统时间按本地规则“硬解”成 struct_time，一旦系统时区没设对（比如 Linux 默认是 UTC），输出就偏了。
常见现象包括：
- Linux 服务器上跑的爬虫，日志时间比北京时间早8小时
- 同一段代码在 Windows（自动设为东八区）和 Docker 容器（常为 UTC）里结果不一致
- 用
datetime.now()和time.localtime()输出的时间看起来一样，但传给某些 API（如闲鱼签名）时校验失败
datetime.now().astimezone() 是更可靠的本地时间获取方式
相比 time 模块，datetime 配合 astimezone() 能显式绑定时区，避免隐式依赖系统配置。关键不是“换模块”，而是“让时区可感知”。
推荐写法：
立即学习“Python免费学习笔记（深入）”；
from datetime import datetime
import zoneinfo # Python 3.9+ 内置；3.6–3.8 用 backports.zoneinfo
<p>beijing = zoneinfo.ZoneInfo("Asia/Shanghai")
now_beijing = datetime.now(beijing)
timestamp_ms = int(now_beijing.timestamp() * 1000) # 毫秒级时间戳，适配闲鱼等接口
formatted = now_beijing.strftime("%Y-%m-%d %H:%M:%S")
要点：
- 不用
pytz（已过时，且与datetime新 API 不兼容） -
zoneinfo.ZoneInfo是标准库方案，无额外依赖 - 直接用
now_beijing.timestamp()得到带时区校准的时间戳，比先取time.time()再转本地更安全
requests 或 API 请求中时间戳偏差导致签名失败
像闲鱼、百度图片这类接口，要求 timestamp 参数必须是毫秒级、且与服务器时间误差控制在几秒内。如果本地时间不准，或时区处理错误，签名就会失效，返回空数据或 401。
典型错误链：
- 用
int(time.time() * 1000)→ 得到的是 UTC 时间戳（因为time.time()永远返回 UTC 秒数） - 但服务端按北京时间（UTC+8）校验 → 实际偏差 8 小时 → 签名过期
- 用
datetime.now().timestamp()→ 若未指定 tzinfo，仍可能返回 UTC 时间戳（取决于系统）
正确做法：
- 统一用带
ZoneInfo("Asia/Shanghai")的datetime实例生成时间戳 - 上线前用
ntpdate -q pool.ntp.org或timedatectl status检查服务器系统时间是否同步 - 避免在签名逻辑里拼接字符串再哈希，先确保
timestamp变量值本身准确
Windows / macOS / Linux 时区行为差异容易被忽略
同一段 datetime.now().astimezone() 代码，在不同系统上表现可能不同：
- Windows：通常自动读取控制面板时区，
astimezone()默认返回本地时区时间 - macOS：类似，但需确认
systemsetup -gettimezone输出是否为Asia/Shanghai - Linux（尤其容器）：默认无时区，
/etc/localtime可能软链到UTC，此时astimezone()若无参数会返回 UTC
最稳妥的方式始终是显式传入 ZoneInfo，而不是依赖平台默认行为。哪怕只是临时调试，也建议加一句：
assert datetime.now(zoneinfo.ZoneInfo("Asia/Shanghai")).tzname() == "CST"
这行断言能立刻暴露环境时区配置问题，比等爬虫跑半天才发现签名失效要快得多。
