大厂限制包装流嵌套不超过三层，核心是保障可维护性：每增一层都加剧理解成本、放大调试难度、增加资源泄漏风险；推荐用分步函数、builder模式和监控点替代深层嵌套。
大厂规范限制包装流嵌套拓扑不超过三层，核心不是技术做不到，而是为了守住可维护性底线。
嵌套过深会快速放大理解成本
每增加一层包装（比如 BufferedInputStream → GZIPInputStream → CipherInputStream → FileInputStream），调用链就多一次委托、一次状态管理、一次异常转换。初学者容易忽略：不同流的 close() 行为不一致、装饰器的初始化顺序影响解密/解压逻辑、某层抛出的 IOException 实际来自内层但堆栈被截断。三层已是多数人能一次性理清数据流向的极限。
调试和错误定位变得不可控
当读取失败时，异常堆栈可能跨越四五个类，而真正的问题可能只是中间某层的缓冲区大小设得太小，或密钥长度不匹配。初学者往往从最外层开始查，反复验证封装逻辑，却跳过内层流的状态检查。大厂要求“错误必须就近暴露”，而深层嵌套天然掩盖了问题发生的精确位置。
资源生命周期管理极易出错
包装流本质是责任链，但每层都持有对下层的引用。超过三层后：
- 手动 close() 容易漏掉某一层，导致底层流未释放；
- 使用 try-with-resources 时，若嵌套构造方式不规范（如中间层抛出异常导致部分流未进入资源列表），会出现静默泄漏；
- 某些流（如 CipherInputStream）在 close() 时会强制完成剩余加解密操作，嵌套越深，失败点越多，恢复逻辑越难设计。
有更清晰的替代结构
大厂不禁止封装，而是鼓励用显式、分步、可测试的方式组织IO流程：
- 把解压、解密、字符编码等步骤拆成独立函数，输入输出类型明确；
- 用 Builder 模式组装流，强制声明各层意图（如 StreamBuilder.from(file).gzip().aes256(key).utf8()），而非靠 new 堆叠；
- 关键路径上插入监控点（如记录每层处理耗时、字节数），这些在扁平结构中更容易注入。
