注解机制：为什么用注解
PHP 开发者看 Java 代码最大的冲击就是「满屏的
@」：@RestController、@Service、@Autowired…… 这到底是什么？一句话：注解是「写给框架看的元数据」，它把「在 Laravel 里靠配置文件/路由文件描述的信息」直接贴在代码元素旁边。
注解 = 附加在代码上的标记
Laravel 里你想声明「这是个控制器」，靠的是目录位置 + 约定（app/Http/Controllers/ 下的类就是控制器）。Spring 里你显式标注：
@RestController // 告诉框架：这是个 REST 控制器
public class PostController {
@GetMapping("/posts/{id}") // 告诉框架：这个方法处理 GET /posts/{id}
public Post show(@PathVariable Long id) {
return ...;
}
}注解本身不写任何逻辑，它只是数据。真正干活的是「读取注解并做出反应的框架代码」。这就是注解的本质：元数据 + 反射驱动的约定替代方案。
一句话类比
注解 ≈ Laravel 里写在类上的一行特殊注释，但框架能读懂它，并据此替你接线。它把「路由表」「中间件注册」「依赖绑定」从配置文件里搬到了代码旁边。
为什么 Java 世界如此依赖注解
因为你没有别的选择 —— 这是对比 PHP 时最容易困惑的点：
PHP/Laravel 的做法
routes/web.php → 声明路由
config/services.php → 绑定实现、配置
app/Http/Kernel.php → 注册中间件
app/Providers/... → 注册服务一个类属于哪一层、路由是什么、依赖怎么注入，散布在很多文件里。
Java/Spring 的做法
@Controller + @GetMapping → 路由声明在方法上
@Service → 声明业务层
@Component → 声明受管 Bean
@Autowired / 构造器 → 声明依赖一个类是什么角色，写在它自己头上。框架启动时扫描（Component Scan）所有类，读到注解就装配。
为什么 Java 必须这么做？
- PHP 可以靠「目录约定 + 自动加载」猜出来：
Models/下的就是模型 - Java 没有
Models/这种约定目录，全靠包 + 注解显式声明 - Java 是静态编译语言，运行时反射是「动态化」的主要手段，注解恰好是「让反射可配置」的载体
一句话：Laravel 用「约定 + 配置文件」，Spring 用「注解 + 扫描」，殊途同归，都是为了「减少重复代码」。
注解的类别：三张牌
| 类别 | 例子 | 作用 |
|---|---|---|
| 标记型 | @Service、@Component | 只做标记，让扫描器知道「这个类要管起来」 |
| 配置型 | @GetMapping、@RequestParam | 携带参数，框架读取后决定行为 |
| 行为型（AOP） | @Transactional、@Cacheable | 触发横切逻辑，如事务、缓存 |
@Transactional // 行为型：方法被代理包裹，自动开/提交事务
public void transfer(Long from, Long to, BigDecimal amount) {
...
}TIP
@Transactional 这类「行为型」注解背后是 AOP 动态代理：Spring 给 Bean 生成一个代理对象，在执行方法前后插入事务逻辑。相当于 Laravel 的 DB::transaction(function(){...}) 被自动包了一层。这是后续 数据库 章节的基础。
注解的生命周期与作用范围
一个注解能被谁读取，由它自己的定义决定：
@Retention(RetentionPolicy.RUNTIME) // 运行时还保留（框架反射才能读到）
@Target(ElementType.TYPE) // 只能标注在类上
public @interface MyMarker {
String value() default "";
}@Retention | 保留到哪里 |
|---|---|
SOURCE | 编译后丢弃（如 Lombok 的 @Data，编译期就用完） |
CLASS | 编译期保留，运行时不读（少见） |
RUNTIME | 运行时保留，框架靠反射读取（Spring 的注解都是这类） |
@Target | 能标在哪 |
|---|---|
TYPE / METHOD / FIELD / PARAMETER | 类 / 方法 / 字段 / 参数 |
有趣的对照
Lombok 的 @Data 是 SOURCE 型：它只在编译期被 Lombok 编译器插件读取，自动生成 getter/setter，产物字节码里注解就没了。Spring 的注解是 RUNTIME 型：运行时要靠反射读。两者「读取时机」完全不同。
组合注解（元注解）
Spring 大量使用「注解上叠注解」，如 @RestController 就是：
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Controller // 组合了 @Controller
@ResponseBody // 和方法返回值自动转 JSON
public @interface RestController { }@SpringBootApplication 同理（组合了三个注解）。这让你写代码时一个注解搞定，而框架能识别到它的「祖先注解」。
Lombok：编译期注解的另一面
Lombok 是「注解在编译期干活的典型」，@Data 自动生成 getter/setter/equals/hashCode/toString，让 Java 实体类瘦身：
@Data
public class User {
private Long id;
private String name;
}等价于手写一大堆 getter/setter。它的原理是编译期 AST 修改：javac 编译时 Lombok 处理器把方法「塞」进类里。所以你的 IDE 需要装 Lombok 插件才能识别。
WARNING
Lombok 是把双刃剑：代码简洁了，但 debug 时看不到 getter/setter 源码、复杂场景下注解处理有坑。团队里用了就统一用，别部分类用部分类不用。
常见认知误区
| 误区 | 真相 |
|---|---|
| 「注解就是注释」 | 不是。框架会在运行时反射读取并驱动行为 |
| 「注解越多越高级」 | 恰恰相反，滥用注解（尤其是行为型）会让行为隐晦 |
| 「没有注解就没办法」 | 也可以 XML 配置，Spring 早期就是 XML。注解只是更内聚的方式 |
小结
- 注解 = 元数据：描述「这个类/方法/字段是什么、该被怎么处理」
- 框架 = 读者：启动时扫描、反射读取、按注解装配
- 对比 Laravel：配置从「外部文件」搬到了「代码旁」，更内聚但更隐晦
- 行为型注解（
@Transactional等）背后是 AOP 代理，是 Java 的高级武器
接下来进入实战，从第一个主题开始：路由。