Java注解本质是元数据标记，不执行逻辑；Spring通过运行时反射读取注解，结合组件扫描、配置解析和AOP代理三步联动，将@Transaction等注解转化为实际行为。

Java 注解本身不执行任何逻辑，它只是元数据标记；Spring 实现声明式配置的关键，在于运行时读取这些注解，并结合 AOP、Bean 生命周期和代理机制，自动织入对应行为。

注解作为“指令标签”，不直接干活

比如 @Transactional、@Service、@Configuration 这些注解，编译后保留在字节码中（由 @Retention(RetentionPolicy.RUNTIME) 保证），但它们自身没有方法体，也不触发任何动作。Spring 容器启动时，会通过反射扫描类和方法上的注解，把它们当作配置意图来解析——相当于“看懂了你的要求”，而不是“注解自己去执行”。

Spring 如何把注解变成实际行为

核心靠三步联动：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 组件扫描与 Bean 注册：@Component、@Service 等模式注解被 @ComponentScan 扫描到后，Spring 将其对应的类识别为候选 Bean，并注册进 IoC 容器
• 配置类解析与 Bean 构造：@Configuration 类被特殊处理，其中用 @Bean 标记的方法会被 Spring 拦截调用，确保返回对象由容器统一管理（避免 new 出来的实例脱离管控）
• AOP 动态代理织入逻辑：@Transactional、@Cacheable 等行为型注解，依赖 Spring AOP。容器为标注了这些注解的 Bean 创建代理（JDK Proxy 或 CGLIB），在方法调用前后自动插入事务开启/提交/回滚、缓存读写等增强逻辑

为什么必须是运行时注解 + 反射 + 代理

因为编译期注解（如 @Override）只对编译器有效，无法在运行时被框架读取；而 Spring 的所有扩展能力都发生在应用启动和请求处理阶段。例如：

立即学习“Java免费学习笔记（深入）”；

• @Transactional 方法被调用时，代理对象先检查当前线程是否有事务，再决定新建或加入——这个判断只能在运行时做
• @Value("${db.url}") 的值来自外部配置，Spring 在 Bean 初始化阶段通过 Environment 接口解析占位符并注入，这也依赖运行时上下文
• 自定义注解如 @AccessControl，需配合 @Aspect 编写切面，在目标方法执行前校验权限——切面逻辑必须在方法真正执行前动态介入

一个典型链条：@Transactional 怎么生效

以服务方法加了 @Transactional 为例：

• 启动时，@EnableTransactionManagement 触发事务基础设施注册
• 容器发现该方法有 @Transactional，且所在类已由 DataSourceTransactionManager 管理，则为其生成代理对象
• 业务代码调用该方法 → 实际调用的是代理对象 → 代理在 invoke 中按传播行为决定是否开启新事务 → 执行原方法 → 成功则 commit，异常则 rollback