父容器不能定义子容器的生命周期与作用域，因父子容器不共享bean定义元信息；子容器可安全访问父容器单例bean，但同名bean会被子容器覆盖，且双方生命周期独立管理。
父容器注解上不能直接“定义”子容器的生命周期与作用域，因为Spring父子容器之间**不共享Bean定义元信息**，生命周期和作用域是Bean自身的属性，由其所在容器独立解析和管理。所谓“安全匹配”，核心不是让父容器“复制”子容器的配置，而是确保：父容器中声明的Bean在被子容器继承或引用时，行为可预期、不冲突、不泄漏资源。
明确父子容器的Bean可见性边界
子容器能访问父容器中已创建的单例Bean（如@Service、@Component），但父容器完全不可见子容器定义的Bean。这意味着：
- 父容器里用
@Scope("singleton")声明的Bean，在子容器中getBean()拿到的是同一个实例——这是安全的，默认即如此； - 若子容器需
@Scope("prototype")行为，不能靠父容器“配成一样”，而必须在子容器自己的配置类或组件扫描路径中独立声明该Bean； - 父容器中带
@PostConstruct或init-method的Bean，其初始化逻辑只在父容器刷新时执行一次，子容器不会重复触发。
避免同名Bean覆盖引发的生命周期错乱
当父子容器都定义了相同beanName的Bean时，子容器的Bean会覆盖父容器的——这会导致看似“复用”实则“替换”，初始化/销毁回调可能只走子容器版本，父容器的清理逻辑被跳过。安全做法是：
- 严格区分命名空间，例如父容器Bean用
coreUserService，子容器用tenantUserService； - 不在子容器中通过
@Import或@ComponentScan意外引入父容器已声明的同类组件； - 若必须复用逻辑，优先抽取为普通工具类或
@ConfigurationProperties对象，而非直接复用带生命周期的Bean。
跨容器场景下作用域与销毁的协同要点
父子容器有各自独立的关闭流程。父容器先关闭时，其单例Bean的@PreDestroy或destroy-method会被调用；此时若子容器仍在运行并持有对该Bean的引用，就可能引发空指针或状态不一致。保障安全的关键是：
- 避免子容器Bean强依赖父容器中非全局稳定服务（如连接池、缓存客户端），这类Bean应由子容器自行管理生命周期；
- 对必须跨容器共享的状态型Bean（如配置中心监听器），使用事件驱动（
ApplicationEvent）或回调注册，而非直接持有引用； - 子容器关闭前，主动调用
ConfigurableApplicationContext.close()，确保其内部DisposableBean和destroy-method正常执行，不依赖父容器兜底。
用@Primary + @Qualifier 控制注入来源，而非靠作用域对齐
有时误以为“让父子容器Bean作用域一致就能自动选对”，其实Spring的依赖注入依据的是BeanFactory层级查找规则，不是作用域匹配。更稳妥的方式是：
- 在父容器中为共享Bean标注
@Primary，子容器中同名Bean用@Qualifier("subUserService")显式指定； - 子容器内需要原型语义时，不要试图“让父容器也变prototype”，而是用
ObjectProvider<mybean></mybean>或@Lookup方法按需获取新实例； - Web环境（如Spring MVC + Spring Boot）中，
request、session等作用域天然绑定到当前容器上下文，无需、也不能在父容器中声明。
