生产环境推荐使用 iso 8601 时间格式，因其统一时区标识（如 z 或 +08:00）、天然可排序、跨系统零兼容成本、调试审计直观可靠。
生产环境推荐使用 ISO 8601 时间格式，核心原因就一个：它让时间变成可交换、可比较、可信赖的“标准零件”，而不是依赖上下文猜测的“方言”。尤其在分布式系统、多时区用户、前后端分离架构中，用错格式轻则日志错乱、排序失败，重则订单跨天、调度失效、审计出错。
避免时区歧义，统一用 UTC + Z 后缀
本地时间（如 2026-05-12 12:43:00）没有时区信息，不同服务器解析结果可能差 8 小时。ISO 8601 强制要求标注时区：
- Z 后缀 = UTC 时间：如 2026-05-12T12:43:00Z，全球唯一含义，数据库、日志、API 都能直接理解
- 偏移量明确：如 2026-05-12T20:43:00+08:00，说明是北京时间，但建议后端统一转为 Z 存储
- 不写时区（如 2026-05-12T12:43:00）是危险操作，Nginx 的
$time_iso8601变量默认带 Z，就是为此规避风险
字符串天然可排序，省去解析开销
ISO 格式按“年→月→日→时→分→秒”升序排列，字典序 = 时间序：
- 2026-05-12T12:43:00Z 2026-05-12T12:43:01Z 2026-05-12T12:44:00Z
- 日志文件名用
access-2026-05-12T12:43:00Z.log，直接ls就按时间排序 - 数据库索引或 Elasticsearch 中对 ISO 字符串字段建索引，范围查询高效稳定
跨语言、跨系统零兼容成本
JavaScript、Python、Java、Go、MySQL、PostgreSQL、Elasticsearch……全部原生支持 ISO 8601：
- 前端：
new Date().toISOString()→ 2026-05-12T12:43:00.123Z - Python：
datetime.now(timezone.utc).isoformat()→ 2026-05-12T12:43:00.123456+00:00 - MySQL：
SELECT NOW() AT TIME ZONE 'UTC'或直接存TIMESTAMP类型（自动按服务器时区转 UTC 存储） - Nginx：
$time_iso8601变量输出即为 2026-05-12T12:43:00+00:00（注意：Nginx 默认不带 Z，而是 +00:00，语义等价）
调试与审计更直观、更可靠
当报警触发、日志告警、审计回溯时，你不需要打开计算器换算时区：
- 看到 2026-05-12T04:15:22Z，立刻知道是 UTC 凌晨 4 点 15 分，对应北京时间中午 12:15:22
- 对比两个服务日志时间，直接字符串比大小：
"2026-05-12T04:15:22Z" 成立 - 排查“订单创建早于支付”的异常？查
created_at和paid_at字段，全是 ISO 格式，一眼识别逻辑错误
