场景

面试或排障若只背 Bean、AOP、MVC 和事务的零散答案，很难解释它们在一次真实请求中如何协作。

原理

请求先由 MVC 分发到控制器，再进入服务 Bean 的代理，切面可开启事务或记录指标，服务通过注入的仓储访问数据。Bean 生命周期决定依赖何时可用，作用域影响共享方式，异常类型和代理边界决定事务是否回滚。

设计步骤

以一次下单请求画调用链；标注每个对象的创建者、作用域和代理类型；追踪参数绑定、校验、异常处理与响应；再模拟同类自调用、受检异常、并发访问和循环依赖，逐项验证实际行为。

权衡

构造注入依赖明确且利于测试，但参数过多会暴露职责膨胀；单例节省创建成本，却要求无共享可变状态。声明式事务简洁，但跨线程、私有方法和未经过代理的调用不会自动获得语义。

实践建议

回答问题时先给定义，再说明底层机制、失效条件和工程选择。项目中使用统一异常处理、类型安全配置与显式线程池。不要用 @Lazy 掩盖架构循环；事务方法保持清晰边界并指定回滚策略。能从请求链解释现象，才算真正掌握。

落地检查

上线前还应做一次桌面演练：准备正常、边界、超时、重复与恶意输入，确认系统的返回、日志和指标彼此对应；在预发布环境模拟依赖不可用、进程重启和配置回滚，验证降级路径不会放大故障。上线时采用小流量观察，提前定义停止条件与负责人。稳定后复盘真实数据，删除没有收益的复杂度，并把新发现的约束补进测试、监控和设计记录，使方案能够随业务持续演进，而不是停留在一次性评审结论。