AuthorizationCodeGrantBuilder为何无accessTokenResponseClient配置方法？

这个设计本质是Spring Security OAuth2客户端模块做分层设计时的主动选择，不是功能遗漏，核心逻辑如下：

• 首先是明确的职责边界划分：AuthorizationCodeGrantBuilder的定位是构建授权码模式的通用核心流程组件，只负责实现OAuth2授权码流程的标准化公共逻辑——包括授权请求构造、参数校验、令牌响应结构解析等不绑定具体业务场景的逻辑，属于底层通用组件。
• 其次是避免场景配置互相干扰：OAuth2AccessTokenResponseClient的自定义逻辑通常和上层接入场景强绑定。同样是授权码流程，用在OAuth2登录场景（对应OAuth2LoginConfigurer）和用在纯服务间OAuth2鉴权场景（对应OAuth2ClientConfigurer）时，你可能需要给令牌请求加完全不同的自定义参数、请求头或者错误处理逻辑。如果把这个配置入口下沉到通用的GrantBuilder层，很容易出现不同场景的自定义配置互相覆盖、污染的问题。
• 另外你提到的「统一添加自定义逻辑、避免配置分散」的诉求，不需要把配置入口放到GrantBuilder就能实现：如果你的自定义逻辑是全局通用的，直接在声明DefaultAuthorizationCodeTokenResponseClient实例时统一封装自定义逻辑，将其注册为Spring容器中的Bean，上层所有场景的配置类都会自动注入这个自定义实例，不需要重复配置。只有当不同接入场景需要不同的令牌客户端逻辑时，才需要在对应Configurer的TokenEndpointConfig#accessTokenResponseClient节点做差异化配置。

补充说明：这个规则不是授权码模式独有的，客户端模式、密码模式等其他授权类型的GrantBuilder同样没有开放令牌响应客户端的配置入口，所有场景特化的配置项统一收敛在对应接入场景的Configurer层，是全模块一致的设计规则。目前没有针对这个单点设计的专项公开说明，这个分层逻辑从Spring Security 5.x版本重构OAuth2客户端模块时就已经确定。

内容的提问来源于stack exchange，提问作者Moary Chan