Spring 全限定 Bean 命名后注入失败：收窄命名范围

为了消除多个配置类中同名 @Bean 方法的冲突，把 FullyQualifiedConfigurationBeanNameGenerator 设到 Spring 应用后，原来能启动的自动配置反而注入失败。先检查被改名的是哪些 Bean：Spring 7 的这项策略不仅影响组件类名，也会改变配置方法的默认 Bean 名。

例如默认名原来是 client，采用全限定配置方法命名后会变成类似 com.example.GeneratedConfig.client。依赖显式限定名称或既有默认名的引用不会自动跟着改写。类型仍然存在，并不能证明按名装配仍然有效。

只为确实冲突的自有代码改名

少量冲突时，优先在自己的 @Bean 上显式指定有意义的唯一名称，并同步检查引用它的限定符、资源注入、表达式和测试。显式名称会优先于生成器推导；没有必要把整套框架 Bean 都改成新命名。

大量生成配置需要统一策略时，可将自定义生成器限制到受控的生成代码包。对框架及第三方包保留默认方法命名，对已有显式名称也保留原值。使用子类时还要区分组件类命名和配置方法命名两个入口，只限制其中一个，未必限制住另一种变化。

不要在无法修改的第三方配置上反复加限定符来追赶全局重命名。若原方案已经让框架 Bean 失配，先恢复原命名配置，再对自己的冲突范围逐步调整，保留每一步的配置差异。

核对生成器实际设置在哪里

@SpringBootApplication(nameGenerator=...) 涉及组件扫描；通过 SpringApplication 设置生成器还会影响应用上下文的配置处理。两处名字相似，不能据此认定它们在当前 Boot 与 Framework 组合下完全等价，也不要机械地在两处各设一次。

Spring Framework 7.0.10 的全限定配置生成器会保留显式 Bean 名，否则使用“声明类全限定名.方法名”。选择这个策略前，应清点应用是否依赖未显式声明的方法名。这是配置范围的兼容性问题，不能仅凭一次启动失败认定 Spring Boot 不支持任何自定义生成器。

验收要查看最终 Bean 名与对应引用，而不只看容器里有同类型对象。测试通常有自己的启动上下文，不一定调用生产入口的 main 方法，应分别确认测试和应用采用了同一预期策略。恢复标准是冲突的自有 Bean 能区分、框架约定名称保持、原来的限定注入与业务调用都通过。