运行时异常不能隐式传递构建校验层，应作为统一出口配合织入机制实现零侵入校验：输入在调用前拦截、输出在返回后检查，异常继承统一基类，通过装饰器、字节码增强或服务网格在边界自动触发并透传上下文。
运行时异常本身不能“隐式传递”来构建校验层——这是个常见误解。真正可行的路径，是把运行时异常作为校验失败的统一出口，再配合不修改业务代码的织入机制，让校验自动触发、自动报错、自动携带上下文。
校验逻辑必须与业务逻辑彻底解耦
业务方法体里不该出现任何 if (x == null) 或 throw new ValidationException()。校验应发生在调用边界：
- 输入校验在函数执行前拦截
- 输出校验在函数返回后检查
- 所有异常都继承自统一基类（如
BusinessValidationException），便于全局捕获和标准化处理
这样，哪怕接口迭代十次，只要类型注解或契约没变，校验逻辑就无需动一行。
用装饰器实现 Node.js 零侵入输入校验
以 @guardInput 为例，它不依赖运行时反射，而是解析 JSDoc 的 @param 或 TypeScript 类型定义：
- 自动提取字段路径（如
user.profile.avatar.url） - 若传入
undefined却声明为string，立即抛出带traceId和完整路径的InputValidationError - 异常对象天然注入当前请求的链路标识，无需手动透传
只需三步：安装包、入口启用全局开关、加装饰器。不改函数签名、不解构逻辑、不加 try-catch。
借助 Spring Boot 4.0 的 AgentReady 模式织入校验
启用 spring.main.agent-ready=true 后，可通过字节码增强在任意 service 方法入口插入校验逻辑：
- 切点匹配
execution(* com.example.pay..*(..)) - 提取参数中
amount字段，非正数则抛BusinessValidationException - 全局
@ControllerAdvice统一转为 HTTP 400，且保留原始 traceId
整个过程对业务代码零修改，连注解都不用加——规则由外部配置驱动。
在服务网格数据面做跨语言协议级拦截
Istio Sidecar 可在请求到达业务进程前完成校验：
- 从 HTTP header 提取
x-trace-id，从 gRPC payload 解析结构 - 若上游 Python 服务发来空
session_id，Sidecar 直接返回 400 并记录日志 - 请求根本不到达 Go 后端，避免无效资源消耗
所有校验失败都复用同一套错误码规范和上下文透传逻辑，确保全链路语义一致。
不复杂但容易忽略
