Clock不是替代System.currentTimeMillis()，而是升级时间抽象：提供可注入、可测试、支持时区的显式时间源，适用于多时区、单元测试和架构解耦场景，而后者仅适合简单时间戳获取。
System.currentTimeMillis() 和 Java 8 的 Clock API 都能获取当前时间戳（毫秒值），但设计目标和适用场景完全不同。直接替换语法很容易，但真正价值在于 Clock 带来的可测试性、时区灵活性和架构清晰度。
核心差异：不是“替代”，而是“升级抽象”
System.currentTimeMillis() 是一个静态工具方法，返回系统时钟的原始毫秒数，没有任何上下文信息；Clock 是一个可实例化、可注入、可替换的抽象类，封装了“如何获取当前时间”这一行为。
- Clock 实例可以绑定特定时区（如 Clock.system(ZoneId.of("Asia/Shanghai"))），而 System.currentTimeMillis() 总是 UTC 基准，时区转换需额外手动处理
- Clock 支持固定时间（Clock.fixed(Instant.now(), ZoneOffset.UTC)），这对单元测试至关重要——你可以让所有时间相关逻辑在“同一时刻”运行，避免 flaky test
- Clock 可以被 Spring 等框架统一管理或注入，业务代码依赖 Clock 接口而非具体实现，便于隔离时间源（比如模拟慢钟、网络延迟钟、回放日志钟）
性能与使用场景
两者底层大多仍调用 System.currentTimeMillis()，所以单次调用性能几乎无差别。关键区别在使用意图：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 如果只是记录日志时间戳、计算耗时、生成简单序号，System.currentTimeMillis() 足够轻量，无需引入 Clock
- 如果涉及多时区展示（如用户本地时间 vs 服务器时间）、需要 mock 时间做测试、或构建可观测性组件（如指标打点带时区标签），Clock 是更合理的选择
- Clock.millis() 和 Instant.now().toEpochMilli() 性能相近，但前者更明确表达“我只要毫秒数”，后者创建 Instant 对象有轻微开销；高频调用场景（如风控限流）可优先用 millis()
实际编码建议
不推荐全局静态替换，而应按职责分层选择：
立即学习“Java免费学习笔记（深入）”；
- 基础设施层（如日志框架、监控 SDK）可封装自己的 Clock 实例，支持配置时区或冻结模式
- 业务服务中，将 Clock 作为构造参数或 @Autowired 依赖注入，而不是硬编码调用 System.currentTimeMillis()
- 测试类中用 Clock.fixed(Instant.parse("2026-06-11T10:00:00Z")) 替代时间敏感断言，避免因执行时机导致失败
- 避免滥用 Clock.systemUTC() —— 它虽简洁，但丢失了时区语义；真正需要 UTC 场景（如数据库时间字段）才用，日常显示时间应配合 ZoneId 使用
一句话总结
Clock 不是为了让代码变长，而是把“时间”从隐式全局状态变成显式可配、可管、可测的协作角色；System.currentTimeMillis() 仍是可靠的底层原语，但不该再是业务代码里唯一的时间入口。
