如何利用 provides 语法实战实现跨模块的异常处理器自动注册与变量处理

坦白说，一上来就想用@provide去实现跨模块的异常处理器自动注册，这路子从一开始就走偏了。行业内对这个装饰器的误解还真不少，今天必须把这件事掰扯清楚。

很多人看到@provide这个关键字，容易联想到后端框架里的依赖注入，比如Guice的@Provides注解。但这里有个巨大的坑：ArkTS里的@provide（注意是小写）是纯粹的UI层装饰器，它的职责非常明确——只在声明式UI节点树里做“状态共享”。说白了，它解决的是“爷爷组件有个状态，孙子组件怎么方便地获取”这类问题，跟后端那一套异常拦截、服务注册机制完全不在一个宇宙。

异常处理器是什么？是应用启动时，框架必须扫描到、注册好、织入请求处理链路里的“服务组件”。它的注册依赖的是Spring Boot的@RestControllerAdvice加包扫描，或者Guice里Module中显式的bind()声明，再或者ASP.NET Core里那一串AddExceptionHandler()的调用。这些工作，UI装饰器一个都干不了。

跨模块异常处理器，到底该怎么注册？

以Spring Boot为例，如果模块A提供了一个全局异常处理器，模块B引用了它却没生效，问题往往出在以下几个环节。逐一排查，基本都能解决：

• 首先，模块A的异常处理器类必须用@RestControllerAdvice标注，并且它所在的包路径，要能被模块B的主启动类扫描到。最直接的方式是在B的启动类上加上@ComponentScan(“com.example.a.advice”)，明确告诉框架去哪里找。
• 其次，模块A需要声明自动配置。在src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.autoconfiguration.imports这个文件里，写下异常处理器自动配置类的全限定名。比如：com.example.a.config.GlobalExceptionAutoConfiguration。
• 然后，这个自动配置类内部，要用@Bean显式地注册GlobalExceptionHandler。为了避免和其他模块的配置冲突，最好再标注一个@ConditionalOnMissingBean，意思是“这个Bean如果还没有，我再来注册”。
• 最后，检查模块B的pom.xml，确保它对模块A的依赖是正确的，并且没有版本冲突。尤其是Spring Boot版本不一致，会导致注解失效这种隐藏得很深的问题。

聊聊@provide的真正用武之地

把UI装饰器和服务治理分开看，事情就清晰多了。@provide最经典的场景，就是解决组件树里“状态透传”的难题。比如你做主题色切换，顶层App组件用@Provide(‘theme’)声明一个ThemeState对象，然后任意深嵌套的按钮、列表、弹窗组件，用@Consume(‘theme’)就能直接绑定并响应变化。状态一变，所有消费组件自动重新渲染。这样一来，就再也不需要为了传一个主题色，在每一层组件里手动塞props了——这才是它设计出来要解决的问题。

所以，“变量处理”这件事，也得分清楚边界。@provide/@consume体系里说的变量，指的是UI组件树内用于驱动视图的“响应式状态变量”。而异常处理器里处理的变量，比如Result、BizException.code、HttpServletRequest，都是框架在运行时注入的，或者由业务逻辑生成的。这两套体系，从技术栈到底层机制，都完全不同。

把两者混为一谈，后果往往是架构上的错位：试图用UI状态管理的逻辑去处理服务治理层面的异常。结果就是异常根本捕获不到，日志里查无此错，HTTP状态码乱飞，前端拿到的错误体也是缺胳膊少腿的。这不是技术选型的取舍问题，这是概念上的硬伤。