应使用 Instant.now() 生成审计时间戳，因其具备跨系统一致的绝对时间特性，避免 LocalDateTime 因缺失时区导致的可比性与歧义问题。
直接用 Instant.now()，别转 LocalDateTime 或字符串再解析——这是最简、最准、最安全的审计时间戳生成方式。
为什么必须用 Instant 而不是 LocalDateTime.now()
审计日志的核心要求是「可比性」和「不可歧义」：LocalDateTime 没有时区信息，同一台机器上不同时区配置、不同部署环境（如北京服务器 vs 纽约服务器）下产生的 LocalDateTime 值无法对齐；而 Instant 是绝对时间轴上的坐标，天然跨系统一致。
常见错误现象：
- 多个服务写入同一条审计记录，
LocalDateTime.now()显示“2024-05-30 10:00:00”，但实际发生时间相差 8 小时 - 日志聚合平台按时间排序错乱，因为没统一基准时区
- 司法取证时被质疑“这个时间到底指哪一地的本地时间？”
正确做法就是全程保持 Instant 类型：生成 → 传输 → 存储 → 查询，中间不落地为无时区字符串或本地时间类型。
Instant 怎么存进数据库和 JSON 日志
JDBC 4.2+ 和主流 ORM（如 Hibernate 6.0+、MyBatis 3.4+）都原生支持 Instant。别手动调 toEpochMilli() 转成 long 再存——这会丢失纳秒精度，且增加类型转换风险。
推荐操作：
- 数据库字段类型用
TIMESTAMP WITH TIME ZONE（PostgreSQL/Oracle）或DATETIME(6)（MySQL 8.0+），直接PreparedStatement.setObject(idx, instant) - JSON 序列化时禁用 Jackson 的
WRITE_DATES_AS_TIMESTAMPS（即设为false），让它输出 ISO-8601 字符串（如"2024-05-30T08:20:00.123456789Z"），而非长整型毫秒值 - 如果下游系统只认毫秒，用
instant.toEpochMilli()，但注意它是截断（非四舍五入），比如纳秒为999_499_999时仍归入前一个毫秒
审计日志里要不要打印时区或本地时间？
不要在审计字段里存 ZonedDateTime 或 LocalDateTime 作为主时间戳。但可以额外加一个可读性字段供人工查看，例如：
{
"audit_time": "2024-05-30T08:20:00.123456789Z",
"audit_time_readable": "2024-05-30 16:20:00.123 CST"
}
这个 audit_time_readable 应该由日志消费端（如 Kibana、Grafana）动态渲染，而不是在应用层硬编码生成——否则一旦时区规则变更（如夏令时调整），历史日志里的本地时间就可能出错。
关键点：
- 主时间戳永远用
Instant.toString()输出的 UTC 字符串，它带Z后缀，明确表示零时区 - 任何基于
ZoneId.systemDefault()的转换都禁止出现在审计日志生成路径中 - 如果业务强依赖本地时间语义（如“当天操作统计”），那应该在分析阶段用
instant.atZone(ZoneId.of("Asia/Shanghai"))转换，而不是在日志里存转换结果
真正容易被忽略的是：很多团队把 Instant 存进数据库后，又在 DAO 层用 resultSet.getTimestamp() 拿出来再转回 Instant，结果因 JDBC 驱动版本或连接参数（如 serverTimezone=UTC）不一致，悄悄变成系统默认时区时间。绕过这个坑的唯一稳态做法是——从头到尾只用 getObject(idx, Instant.class)。
