应统一使用instant处理时间，localdatetime仅用于前端展示；数据库存instant、通信传instant、日志用instant、业务逻辑禁用localdatetime.now()。
用对 LocalDateTime 和 Instant，能从根上堵住时间相关的并发与一致性漏洞。关键不是“怎么转”，而是“在哪转、为什么这么转”。历史 bug 往往源于把本地时间当全局时刻用、在跨时区场景下依赖系统默认时区、或在存储/传输环节丢失时间语义。
数据库写入：别让LocalDateTime偷偷漂移
LocalDateTime 本身不含时区，但 JPA/Hibernate 默认会按 JVM 时区解释它再存入 MySQL 的 TIMESTAMP 字段——而数据库又可能配置为 UTC。结果就是：应用服务器在东八区，存进去的时间比实际早 8 小时；换到东京服务器部署，偏差变成 1 小时。这不是精度问题，是语义错乱。
✅ 正确做法：
- 实体字段统一声明为 Instant（配合
@Column(columnDefinition = "BIGINT")或数据库TIMESTAMP WITH TIME ZONE） - 若必须用 LocalDateTime 字段，务必配 @Converter，强制按 UTC 转换：
localDateTime.atZone(ZoneId.of("UTC")).toInstant() - 禁用
spring.jpa.properties.hibernate.jdbc.time_zone=SYSTEM这类模糊配置
微服务通信：所有时间戳必须是Instant（且带UTC语义）
两个服务之间传一个 LocalDateTime.now()，等于传一张没坐标的地图——接收方不知道这个“上午9点”是指纽约的9点，还是伦敦的9点，还是服务器所在机房的9点。一旦发生故障排查、日志对齐或超时计算，时间差就会放大成业务逻辑错误。
✅ 正确做法：
- 对外暴露的 DTO 中，所有时间字段类型为 Instant
- 前端传来的“2026-06-05T09:00”这类字符串，在 controller 层立刻解析为
Instant.parse("2026-06-05T09:00Z")或通过LocalDateTime.parse(...).atZone(ZoneId.of("Asia/Shanghai")).toInstant()显式绑定来源时区 - Feign/OpenFeign 调用时，用 String + ISO-8601 格式（含 Z 或 +00:00） 传输，避免 JSON 序列化器自动套上本地时区
前端展示：LocalDateTime 只出现在最后一公里
用户看到的“今天下午3点下单”，必须是用户本地时区理解的时间；但这个时间不能参与任何计算、比较或持久化。把它当成纯视图产物，就像格式化后的金额字符串一样——可读，不可运算。
✅ 正确做法：
- 后端返回给前端的 JSON 中，时间字段仍是 Instant（序列化为 ISO 格式如
"2026-06-05T07:00:00Z"） - 前端用
new Date(instantStr)自动转成本地时间，或 Java 后端在 Controller 层做一次转换：instant.atZone(ZoneId.systemDefault()).toLocalDateTime()—— 仅限于模板渲染或 Swagger 示例 - 禁止在 Service 层、DAO 层、定时任务触发逻辑中出现
LocalDateTime.now()，一律改用Instant.now()
日志与监控：Instant 是唯一可信锚点
同一笔请求在网关、订单、库存三个服务里打的日志，如果都用 LocalDateTime.now()，它们在时间轴上根本无法对齐。尤其当服务分布在不同时区的云区域时，“先发生的事件”可能在日志里排在后面。
✅ 正确做法：
- SLF4J MDC 中记录时间戳，只存
Instant.now().toEpochMilli()或直接存Instant对象（Logback 支持） - ELK / Grafana 查询时，统一按 UTC 时间范围过滤，不依赖日志里的“本地时间字符串”
- 异步任务（如 Quartz、XXL-JOB）的执行时间判断，全部基于
Instant.now()与数据库中存储的Instant字段比对，不用LocalDateTime.plusHours(1)这类易受夏令时干扰的操作
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
