迭代器的throw捕获深度本质是责任边界清晰度，而非嵌套层数；它在解析、映射、校验等关键隘口逐层封装错误，将格式错、语义错、协议错、业务错统一升维对齐到业务语义层，并通过结构化错误码、上下文快照和影响范围标识支撑智能防腐。
利用迭代器的 throw 捕获深度特性，不是为了“多捕几层”，而是让每层错误在它该出现的位置被识别、封装、传递——从而在统一接口防腐层中，把格式错、语义错、协议错、业务错逐级对齐到同一语义轨道上。
捕获深度 ≠ 嵌套层数，而是责任边界清晰度
所谓“捕获深度”，本质是异常在调用栈中被拦截并升维的层级位置。防腐层要做的，不是在最外层 try-catch 一把抓，而是在数据流入路径的关键隘口设卡：
-
解析层（如 CSV/JSON 解析）捕获
JsonParseException或UnicodeDecodeError，包装为FormatMismatchException("字段 email 格式非法", recordId) -
映射层（DTO → Domain）捕获空指针或类型转换失败，升维为
SemanticMappingException("用户状态码 999 未定义", rawValue) -
校验层（如 JSR-303）不抛
ConstraintViolationException，而是聚合后转为BusinessRuleViolationException("手机号未通过运营商实名验证")
统一防腐接口必须暴露可区分的错误维度
一个只返回 Result<t></t> 的接口无法支撑智能对齐。真正可用的防腐层接口需同时提供：
-
结构化错误码：如
FORMAT_EMAIL_INVALID、RULE_PHONE_UNVERIFIED，而非泛泛的VALIDATION_ERROR - 原始上下文快照：保留出错时的 raw record、字段名、行号、traceId，供后续人工复核或自动补偿
-
错误影响范围标识：标记该错误是否可跳过（
skipable=true）、是否污染批次（batchAbort=true）、是否需人工介入（severity=HIGH）
迭代器作为错误流载体，天然支持“错中取正”
自定义迭代器的 __next__() 或 computeNext() 是唯一适合做“单条记录弹性处理”的地方。它让错误不再中断流，而成为流的一部分：
- 每次
next()调用，内部执行完整解析→映射→校验链，任一环节 throw 都被立即捕获 - 捕获后不终止，而是将错误归类写入本地 error buffer，并推进游标到下一条
- 对外仍保持标准迭代契约：调用方用
for item in it:即得有效数据；另通过it.getErrors()主动拉取错情摘要
多级异构错误最终对齐到业务语义层
不同来源的脏数据（API JSON 字段缺失、数据库 varchar 存了乱码、Excel 单元格为空字符串），经迭代器各层拦截后，全部收敛为同一组业务异常类型：
-
DataMissingException（统一标识“关键字段缺失”，无论来自 null、"" 还是空数组） -
ValueTypeMismatchException（统一标识“类型不兼容”，屏蔽 int/string/boolean 解析差异） -
BusinessConstraintBrokenException（统一标识“违反领域规则”，如余额不足、时间超限）
这样，上层服务只需关注“什么业务条件没满足”，无需感知底层数据源是 MySQL、Kafka 还是 Excel 文件。
