spring boot 不支持自定义注解替代 @autowired 或 @resource 实现依赖注入，因其注入逻辑硬编码在 autowiredannotationbeanpostprocessor 等内置处理器中；自定义注解仅可作为标记，需配合 aop 或工厂模式模拟行为，但非容器原生注入。
Spring Boot 本身不支持“自定义依赖注入注解”来替代 @Autowired、@Resource 或构造器注入这类核心容器行为。依赖注入是 Spring IoC 容器的底层机制，由 BeanFactory 和 AutowiredAnnotationBeanPostProcessor 等内置处理器硬编码支持——你无法通过写一个新注解（比如 @MyInject）就让 Spring 自动完成字段/构造器的依赖查找与赋值。
为什么不能真正“自定义注入注解”
Spring 只识别有限几个元注解驱动的注入点：
-
@Autowired（Spring 原生，按类型注入） -
@Resource（JSR-250，默认按名称，可指定 name） -
@Inject（JSR-330，类似 @Autowired） - 构造器参数（Spring 4.3+ 对单构造器自动应用 @Autowired）
这些注解的处理逻辑写死在 Spring 框架的后置处理器中。即使你用 @interface MyInject 定义了一个注解，并加上 @Retention(RUNTIME) 和 @Target({FIELD, CONSTRUCTOR, METHOD})，Spring 启动时也不会扫描它、更不会执行注入动作——它只是个普通标记，没有语义。
但你可以“模拟”或“增强”注入行为
虽然不能替代原生注入，但可通过以下方式实现类似效果：
-
用 AOP + 自定义注解做运行时赋值：例如定义
@AutoWiredByLogic，再写切面在 Bean 初始化后，根据业务规则（如租户 ID、配置开关）动态从上下文查 Bean 并 set 到目标字段。但这属于手动赋值，不是容器托管的依赖注入，且易出线程安全或生命周期问题。 -
结合 @ConfigurationProperties 或工厂 Bean 封装逻辑：比如定义
@DynamicService("payment")，配合一个ServiceFactoryBean，在运行时根据字符串名返回对应实现类。这本质是策略模式 + 依赖查找，不是注入。 -
用自定义 Starter 统一注册带条件的 Bean：在 starter 中通过
@ConditionalOnProperty或@ConditionalOnClass控制是否创建某个服务 Bean，并用标准@Autowired注入。用户感知的是“配置即生效”，背后仍是 Spring 原生注入机制。
真正该自定义的，是业务场景注解（非注入类）
实践中更常见、也更有价值的自定义注解，是配合 AOP 实现横切逻辑，例如：
-
@LogExecutionTime：记录方法耗时 -
@RequirePermission("ORDER_CREATE")：统一权限校验 -
@Idempotent(key = "#order.userId")：接口幂等控制 -
@Trace：链路追踪打标
这些注解不负责注入，而是作为“触发开关”，由切面读取其属性并执行对应逻辑——它们干净地解耦了横切关注点，这才是 Spring Boot 中自定义注解的正确打开方式。
想让某个字段“被注入”，就老实用 @Autowired 或构造器；想让某个方法“被增强”，才去自定义注解 + AOP。分清边界，才能少踩坑。
