Java 17新增java.time.InstantSource接口相比抽象类Clock的作用是什么

核心设计目的 #

java.time.Clock从Java 8引入时的职责设计偏厚重：作为抽象类，它除了提供当前时间戳能力外，还强制绑定了时区属性，附带getZone()、withZone()等一系列时区相关方法。但现实开发中大量场景只需要获取UTC时间戳，完全不需要关心时区，依赖Clock属于不必要的强耦合，还会增加时区相关的出错概率。
新增的InstantSource是完全遵循接口隔离原则的轻量抽象：它仅定义了instant()、millis()两个获取时间戳的核心方法，完全剥离了时区相关的所有逻辑，开发者只需要依赖自己实际用到的能力即可，不需要为不需要的时区特性买单。
另外作为接口类型，InstantSource比抽象类Clock的自定义实现成本低很多：自定义时间源不需要继承Clock实现大量冗余的时区相关方法，仅需实现两个核心方法即可，适配性更强。

适用场景 #

• 仅需要UTC时间戳的业务逻辑：比如日志时间标记、事件全局时间ID生成、数据版本时间戳赋值等场景，直接依赖InstantSource即可，不需要处理任何时区参数传递、校验逻辑，代码更简洁。
• 单元测试时间mock场景：之前依赖Clock做时间模拟时，必须给mock实例设置一个无意义的时区，用InstantSource只需mockinstant()方法的返回值即可，测试代码更精简，也不会出现时区换算错误的低级问题。
• 跨组件统一时间源场景：多个服务/模块需要共用同一个时间源（比如自定义的偏移时间源、分布式同步时间源）时，对外仅暴露InstantSource接口即可，不需要传递时区信息，从根源上避免不同组件时区设置不一致导致的时间异常。

目前所有InstantSource的实现类同时也是Clock的实现，是为了保证向下兼容：老代码里的Clock实例可以直接赋值给InstantSource类型的变量，迁移成本几乎为零。

内容的提问来源于stack exchange，提问作者Олег Мельник