OffsetDateTime.now() 返回系统默认时区对应的实际偏移时间戳，非UTC+0，也非简单UTC+偏移；其本质是ZonedDateTime转OffsetDateTime，精度与Instant.now()一致，但语义不同，生产环境须显式指定时区。
OffsetDateTime.now() 默认返回的是系统时区的带偏移时间戳
调用 OffsetDateTime.now() 本质是先获取系统默认时区（ZoneId.systemDefault()）对应的 ZonedDateTime，再转成带固定偏移量的 OffsetDateTime。它不是“UTC 时间 + 系统偏移”，而是“系统本地时刻 + 对应时区当时的实际偏移”——比如北京时间（Asia/Shanghai）在夏令时期间仍为 +08:00，因中国不实行夏令时；而欧洲某些地区会动态变更为 +02:00 或 +01:00。
常见误判：以为 OffsetDateTime.now() 总是返回 UTC+0 偏移，或以为它和 Instant.now() 仅差一个格式化。其实二者语义不同：Instant 是纯时间线上的点（无时区概念），OffsetDateTime 是带偏移的本地化表示，两者转换需明确参考点。
业务时间戳必须显式指定时区，不能依赖系统默认
生产环境服务器时区不可控（可能为 UTC、CST、甚至被运维临时修改），靠 OffsetDateTime.now() 默认行为会导致日志时间、订单创建时间、缓存过期判断等出现跨时区错乱。正确做法是业务层统一约定基准时区（通常是 ZoneOffset.UTC 或运营所在地时区）。
- 要 UTC 时间戳（推荐用于存储、跨系统交互）：用
OffsetDateTime.now(ZoneOffset.UTC) - 要北京时间（东八区固定偏移）：用
OffsetDateTime.now(ZoneOffset.ofHours(8))，而非ZoneId.of("Asia/Shanghai")—— 后者返回的是ZonedDateTime，转OffsetDateTime时虽结果常为 +08:00，但逻辑绕路且隐含时区规则解析开销 - 若需“上海本地时间 + 实际偏移”（如面向终端用户的显示），才用
ZonedDateTime.now(ZoneId.of("Asia/Shanghai")).toOffsetDateTime()，但注意这仍可能因历史时区变更（如1949年前后）产生非预期偏移
OffsetDateTime.now() 的精度和时钟源与 Instant.now() 一致
Java 8+ 的 OffsetDateTime.now() 底层调用的是 Clock.systemDefaultZone()，其时间源和 Instant.now() 相同（通常基于 System.nanoTime() 和系统时钟校准），毫秒级精度无差异。但要注意：
- 不要用
new Date().toInstant().atOffset(...)替代——Date的构造函数有已知的时区陷阱，且多一次对象转换 - 高并发场景下频繁调用
OffsetDateTime.now()不会造成性能瓶颈，但若需多次使用同一时间点（如事务内多个字段赋值），应先缓存一个实例，避免微秒级时间漂移 - 测试时若 mock 时间，应替换
Clock实例（如Clock.fixed(...)），而不是试图 patchOffsetDateTime静态方法
容易忽略的序列化与数据库写入问题
OffsetDateTime 本身不含时区 ID，只含偏移量（如 +08:00），因此序列化为 JSON 时（如 Jackson 默认）会输出类似 "2024-05-20T14:30:45.123+08:00" 的字符串；写入 PostgreSQL 的 timestamptz 字段时，JDBC 驱动会自动按偏移转换为 UTC 存储。但以下情况会出问题：
- MySQL 旧版本（OffsetDateTime 写入
datetime字段会截断毫秒，且不校验偏移合法性 - MyBatis 等框架若未配置
typeHandler，可能把OffsetDateTime当作String处理，导致 SQL 注入或格式错误 - 前端传回的 ISO 8601 字符串（如
"2024-05-20T14:30:45+08:00"）被 Jackson 反序列化时，若未配置JavaTimeModule，会抛InvalidDefinitionException
真正关键的不是“怎么拿到时间”，而是“拿到后是否在所有环节保持偏移语义不变”。偏移量一旦丢失或误转，业务时间就不再是可追溯的精确锚点。
