stream流与自定义异常拦截器不应结合，因二者分属数据处理与错误响应治理不同职责层；stream应仅做无副作用的数据变换，异常统一由@restcontrolleradvice兜底处理。
Stream 流只负责数据加工，不参与异常门面设计
Stream 是 Java 8 引入的函数式数据操作工具，用于对集合、数组等做转换（map）、过滤（filter）、聚合（reduce）等。它本身不抛业务异常，也不感知 HTTP 协议、状态码或响应结构。
常见误用场景：
- 在 Stream 的 map 或 filter 中 throw new BusinessException("用户名非法") —— 这会让异常穿透到 Controller 层，但丢失上下文（如哪个元素出错）、无法定位原始参数、且破坏 Stream 的声明式语义
- 试图用 Stream + try-catch 包裹每个操作来“自动清洗”——结果是代码臃肿、错误信息碎片化、日志难追踪
正确做法：清洗逻辑应前置到 DTO 绑定、参数校验（@Valid）、或 Service 入口处完成；Stream 内只做纯函数式变换，保持无副作用。
异常拦截器只负责统一兜底，不介入数据流过程
@RestControllerAdvice 的核心价值是“收口”：把散落在各处的异常，按类型归一为标准 JSON 响应（code/msg/data/timestamp）。它不关心数据怎么来、怎么变，只关心“出错了，怎么告诉调用方”。
它不该也不需要：
- 监听 Stream 执行过程（Stream 没有事件钩子）
- 在拦截器里重写 Stream 逻辑（违反单一职责）
- 为每个 Stream 操作单独定义异常码（造成码表爆炸）
真正要拦截的，是业务方法抛出的 CommonException、参数校验失败（MethodArgumentNotValidException）、以及运行时系统异常（如 NPE、SQLEx），这些才对应明确的 HTTP 状态码和前端可处理的 code。
所谓“洁净门面”，靠的是三层协同，不是技术拼接
一个对外稳定、内聚干净的 API 门面，依赖的是职责分离的三层配合：
- 接入层清洗：用 @Valid + @Validated 校验请求体/路径变量/查询参数，失败由拦截器自动转为 400 + 字段级错误列表
- 服务层断言：Service 方法开头用 Assert.notNull() 或 if (xxx == null) throw new CommonException(1003, "用户不存在")，统一走拦截器返回 404 或 400
-
响应层封装：所有 Controller 返回 Result
，成功走统一 success() 构造器，失败全靠 throw，绝不手动 new ResponseEntity
Stream 如果出现在 Service 中，仅作为内部实现细节存在，对外不可见——就像数据库 SQL 怎么写，前端不需要知道。
如果真想“自动清洗”，重点在参数与DTO设计
所谓“全自动清洗”，本质是减少人工校验和容错判断。可行路径是：
- 用 @NotBlank、@Pattern、@Min 等 Bean Validation 注解声明式约束入参，框架自动拦截并聚合报错
- DTO 字段加 @Convert，配合 Converter 实现字符串 → 枚举 / 时间戳 → LocalDateTime 的自动安全转换
- 用 MapStruct 或 ModelMapper 做对象映射，避免手写 set/get 导致空指针或类型错位
- 关键字段（如 ID、手机号）在 Controller 入参处就做非空+格式校验，不让脏数据进 Service 层
这些才是让门面“洁净”的真实抓手，不是靠把 Stream 和异常处理器绑在一起。
