大厂多业务线共存时，aop切面必须严格隔离：注解需带业务前缀并置于模块专属包，反射扫描须白名单控制，切点限定包路径，运行时校验模块上下文并支持动态开关。
大厂级多业务线共存时，切面（AOP）若未严格隔离，极易因注解命名模糊、反射范围失控，导致一个模块的切面逻辑意外作用于兄弟模块——比如订单模块的 @LogTrace 被风控模块的同名注解触发，引发日志错乱、权限校验重复执行甚至事务干扰。核心不是禁用切面，而是让注解“有身份、有边界、有归属”。
注解必须带业务域前缀，禁止通用名裸用
所有自定义注解名称需显式绑定所属模块，避免跨模块语义冲突：
- ✅ 正例：
@OrderLogTrace、@UserAuthCheck、@MarketingCouponLimit - ❌ 反例：
@LogTrace、@AuthCheck、@Limit（这些在多个模块中极易重复定义，且 Spring 的@Aspect扫描无法区分来源） - 注解类本身应放在模块专属包下，如
com.mycompany.order.aop.annotation.OrderLogTrace，配合模块化系统（Java 9+）限制跨模块访问
反射层必须白名单驱动，禁止通配扫描
切面底层依赖反射查找目标类/方法，若不限制范围，ClassPathScanningCandidateComponentProvider 或 Reflections 库可能扫到兄弟模块的类，造成误织入：
- 禁用
@ComponentScan(basePackages = "com.mycompany")这类宽泛配置；改为按模块精确指定：@ComponentScan(basePackages = "com.mycompany.order.service") - 切面类中使用
@Pointcut时，必须限定包路径或类名前缀：
execution(* com.mycompany.order..*.*(..))，而非 execution(* com.mycompany..*.*(..)) - 若需动态注册切点（如插件化场景），用白名单配置文件（如
aop-allowed-modules.yml）控制哪些模块可被当前切面匹配，启动时校验并拒绝非法项
运行时加装反射防护网，拦截越界调用
即使编译期规范到位，运行时仍可能因类加载器混杂、热部署或测试 mock 引入污染。需在反射关键路径设防：
- 重写或包装常用反射工具类（如
BeanUtils、ReflectionUtils），在getDeclaredMethod/invoke前检查调用栈：若上两层类来自非本模块包（如com.mycompany.marketing.*），直接抛SecurityException - 结合 Java 模块系统，在
module-info.java中仅exports公共 API 包，将切面注解与反射工具类置于internal.aop包且不导出，外部模块无法直接引用 - CI 阶段用 SpotBugs 插件检测
Class.forName("com.mycompany.*")或Method.invoke等高危反射调用，强制要求附带模块归属断言
切面行为必须可追溯、可开关、可隔离
防止误伤的最后防线是让每个切面具备“身份感知”和“熔断能力”：
- 每个
@Aspect类声明唯一@Order值，并通过@Profile("order-aop")绑定模块环境，避免多模块 AOP 同时激活 - 切面内部逻辑开头即校验当前执行上下文是否属于本模块：
if (!ModuleContext.isIn("order")) return;（ModuleContext由启动时注入的模块标识驱动） - 提供运行时开关：通过
@Value("${aop.order.logtrace.enabled:true}")控制开关，故障时可立即关闭某模块切面，不影响其他模块
