spring boot 默认仅扫描启动类所在包及其子包，若组件（如@service、@repository、@entity）不在该路径下，则不会被注册——这是组件扫描失效的根本原因；正确做法是统一包结构或将@componentscan显式指定扫描范围。
编译容器缓存本身不会导致装饰器注入失效——真正出问题的是构建过程中依赖注入环境被破坏，或运行时容器未按预期加载装饰器逻辑。所谓“缓存导致失效”，其实是缓存层掩盖了配置、初始化或生命周期管理上的缺陷。
确认装饰器是否真被容器识别
很多“失效”现象源于装饰器未被正确注册进容器上下文。例如在 Spring 中，@Component 或 @Service 类若不在组件扫描路径下，即使加了注解也不会被托管；在 CodeIgniter 4 中，自定义服务未在 app/Config/Services.php 显式注册，$this->service('MyDecorator') 就会返回 null。
- 检查框架是否启用自动扫描：Spring 要确认
@ComponentScan包含目标类，CI4 要确认Services::injectMock()或add()已调用 - 验证装饰器类是否满足容器要求：如 Spring 要求非 final、有可访问构造函数；CI4 要求构造参数全为容器可解析类型（或带默认值）
- 运行时打印容器中已注册的服务列表（如 Spring 的
ctx.getBeanDefinitionNames()），搜索你的装饰器类名
构建缓存干扰了依赖注入链
Docker 或 CI 构建中若缓存了旧版 vendor/ 或 target/ 目录，可能导致类加载顺序错乱、字节码版本不匹配，进而使 AOP 代理失败、@Autowired 字段未填充、或装饰器的 InvocationHandler 未生效。
- CI 流水线中禁用
vendor/缓存，只缓存~/.composer/cache（PHP）或~/.m2/repository（Java） - Docker 构建时，在
COPY前加RUN rm -rf vendor/（PHP）或RUN mvn clean（Java），避免复用错误的构建产物 - 若使用 Spring Boot DevTools，确保生产镜像中已移除该依赖，否则可能触发不兼容的类重载机制
装饰器逻辑与容器生命周期不匹配
常见于手动 new 实例、静态方法调用、或在构造函数中过早使用装饰器功能——此时容器尚未完成 Bean 初始化，AOP 代理还未织入，装饰行为自然无法触发。
- 避免在构造函数里直接调用被装饰的方法（如
this.decoratedMethod()），改用@PostConstruct或初始化回调 - 不要在
@Configuration类的@Bean方法里 new 装饰器实例，应让容器统一管理其生命周期 - Python 中若用
@decorator修饰类方法，确保装饰器内部 wrapper 正确接收self，否则绑定失败会导致“看似注入但实际没走装饰逻辑”
验证装饰器是否真正生效
别只看日志或断点，要观察运行时行为：是否执行了装饰器前置逻辑？是否拦截了原方法调用？返回值是否被修饰？
- 在装饰器内加唯一标识日志（如
log.info("✅ Decorator active for {}", method.getName())），部署后查日志确认是否触发 - 用反射检查目标方法是否被代理：Spring 中可通过
AopProxyUtils.ultimateTargetClass(obj)判断是否为 CGLIB 代理 - CI 构建后进入容器执行
java -cp app.jar org.springframework.boot.loader.JarLauncher --debug（Spring）或php -d display_errors=1 index.php（CI4），查看容器启动时是否报注入警告
