Kafka 消费端协议没生效

Spring Boot 4.0.7 同时配置了全局和消费端的 security.protocol，生产者连接正常，消费者却仍按全局协议连接。先检查消费工厂最终使用的配置：这一版自动配置会把消费端协议覆盖为全局值。

这项问题在 4.0.8 已修复，4.1.1 的实现也已采用消费端自己的协议。已经使用包含修复的版本时，认证失败还需检查实际配置来源、凭据和连接入口，不能仅凭消费者连不上就认定遇到了这个缺陷。

看最终协议，不只看配置文件

下面是配置关系的示例片段，不是完整的 Kafka 认证配置：

spring:
  kafka:
    security:
      protocol: SSL
    consumer:
      security:
        protocol: SASL_SSL

它表达消费端需要 SASL_SSL、其他未覆盖的客户端使用全局 SSL。实际协议必须符合对应 broker 的监听器与认证要求；保留项目原有的地址、SASL 机制、凭据和证书配置，不能直接把这段复制成一份可连接的配置。

4.0.7 的消费端自动配置虽然取到了 consumer 的连接信息，却在应用协议时读取了全局连接信息。于是配置文件里的消费端覆盖值存在，最终的 DefaultKafkaConsumerFactory 属性却可能是全局值。生产端读取自己的协议，表现也就可能不同。

记录应用实际运行的 Spring Boot 版本，再检查真正使用的消费工厂中的 security.protocol。只查看这一项及必要的连接身份即可，不要把整个属性表输出到日志：其中可能包含 SASL 凭据。

若应用自建了消费工厂，或者通过连接详情提供了另一套配置，还应确认它们是否经过同一条自动配置路径。环境变量、部署配置与本地文件的优先级也要一起核对。

升级后分别验收三类客户端

在 4.0 维护线上采用包含修复的 4.0.8 或兼容的后续版本，也可按项目原有升级计划选择兼容的 4.1 版本。依赖应按对应 Spring Boot 版本统一管理，保留当前可恢复的应用构建与配置。

修复后的消费端会采用 consumer 自己的协议。检查最终配置，再通过获准的测试主题验证连接、读取及应用原有的处理约定。验证生产者和管理客户端仍使用各自需要的协议，避免消费端恢复后，创建主题或发送消息反而失败。

不要为了绕过旧版覆盖问题，把全局协议也改成消费端需要的值。全局配置可能被生产者与管理客户端使用；也不要退到 PLAINTEXT 或关闭证书校验，这会改变连接的安全要求。

若升级后消费工厂中的协议已经正确，但仍出现认证或 TLS 错误，继续核对 broker 监听器、SASL 机制、身份权限与信任配置。此次修复不会替应用补齐缺失的凭据，也不能修正错误的 broker 地址。

需要撤回时恢复经过审定的应用构建与配套配置，分别复查客户端的实际协议。不要只回退一项依赖，留下混用的 Spring Boot 与 Kafka 组件版本。