注解驱动开发是通过声明式契约剥离行为定义与执行时机，让业务逻辑专注核心职责。@EventListener实现事件解耦，@Valid实现校验前置，@Scheduled与事件结合管理定时/状态任务，底层依托接口抽象与依赖注入支撑解耦。
注解驱动开发不是给代码“贴标签”那么简单，而是通过声明式契约把行为定义和执行时机从主流程中剥离出来，让业务逻辑专注干好一件事，其他事交给框架按规则调度。
用 @EventListener 实现事件响应解耦
在用户注册后发邮件、写日志、更新统计，这些动作和注册本身无关，硬写在 service 里会越积越多。用 @EventListener 就能拆开：
- 定义一个干净的事件类，比如 UserRegisteredEvent，只含 final 字段（userId、timestamp），不依赖 Spring
- 在任意 Bean 的 public 方法上加 @EventListener，参数类型即监听的事件，Spring 自动注册
- 多个方法可监听同一个事件，互不影响；新增一个监听器，不用改注册逻辑
- 需要异步执行时，加上 @Async；需等事务提交后再触发，换用 @TransactionalEventListener(phase = AFTER_COMMIT)
用校验注解实现初始值校验复用
接口入参的格式、范围、非空校验，属于“边界过滤”，不该掺进业务方法里：
- 在 DTO 字段上直接用 @NotBlank、@Min(1)、@Email 等标准注解
- Controller 方法参数加 @Valid，校验失败自动返回 400，业务方法完全不碰 if-else 校验
- 自定义注解（如 @ValidOrderNo）可封装复杂规则，配合 ConstraintValidator 复用到所有订单相关接口
- 校验逻辑集中管理，前端传错字段、长度超限、格式不对，都在进入 service 前被拦住
用 @Scheduled 或 @EventListener 统一管理定时与状态变更逻辑
订单超时关单、库存预警、日志归档这类任务，本质是“对某个状态或时间点做出反应”，不是业务主干：
立即学习“Java免费学习笔记（深入）”；
- 用 @Scheduled(fixedDelay = 60000) 写定时扫描，但更推荐发布事件：比如库存服务检测到低于阈值，publish(new StockLowEvent(sku, level))
- 由独立监听器处理告警、补货建议、通知运营，彼此无调用链路，一个挂了不影响另一个
- 避免在定时任务里塞满业务细节，任务方法只做“触发”，具体响应由事件驱动分散处理
注解背后的关键支撑：接口 + 依赖注入
注解本身不干活，它只是“开关”。真正实现解耦的，是背后那一套接口抽象和运行时注入机制：
- @EventListener 背后是 ApplicationEventPublisher 接口，发布者不关心谁监听，监听者也不知谁发的
- 校验注解靠的是 Validator 接口及其实现（如 Hibernate Validator），替换实现不影响业务层使用方式
- 所有注解生效的前提，是目标类由 Spring 管理——构造器注入保证依赖可替换，不 new 具体实现
- 测试时可直接 mock 监听器或 validator，验证“是否收到事件”“是否触发校验”，不走真实流程
