时区安全规范 服务端代码里，"当前时间"几乎从不应该裸调。一个 docker 镜像默认 UTC、一个生产机配置 Asia/Shanghai，同一份代码跑出来的"本周起点"就差 8 小时。 配套： （性能） / （隔离） --- 陷阱 #1: 裸调 依赖 JVM 默认时区 场景 : / / / 不传时区 问题根因 - 在 UTC 服务器上返回的"今天"比业务时区少 1 天（凌晨场景） - 拿到的是 JVM 默认时区时间，docker base image 经常默认 UTC - 同一段代码在开发机（Asia/Shanghai）和生产（UTC）跑出不同结果，无法本地复现 - 数据库时间通常按业务时区入库，比较时一边是业务时区一边是 UTC → 偏差 8h 错误示例 正确做法 项目级业务时区常量 + 所有 显式传入： 嗅探信号 检查清单 - [ ] 项目内是否有统一的 常量 - [ ] Service / Handler 层禁止裸 ，必须显式时区 - [ ] 可以裸用（UTC 时间戳无歧义） - [ ] 测试用 注入，不要硬编码 --- 陷阱 #2: 周/月/日起点计算缺失时区 场景 : 计算"本周起点 / 本月初 / 今日 00:00"用于统计聚合 问题根因 跨日/跨周/跨月切换时间点最敏感。如果起点用 UTC 算，业务时区下"本周一 0 点"对应 UTC 周日 16:00，导致统计错…