异常堆栈本身不占网络带宽，真正消耗带宽的是日志上报、监控采集或跨进程传递时的冗余数据膨胀；需优化异常包装、日志深度控制、聚合上报及序列化裁剪。
异常堆栈本身不占用网络带宽——它不是传输对象，也不会主动发到远程服务。所谓“带宽占用”，实际发生在日志上报、监控采集或序列化异常对象并跨进程传递时，比如通过 HTTP、gRPC 或消息队列发送错误详情。真正要优化的，是这些环节中堆栈被完整携带所引发的冗余数据膨胀。
只在必要位置包装异常
避免每层都 new XxxException("msg", e)。这种写法会逐层复制 cause 的完整堆栈，导致异常链体积指数级增长。重点只在语义升级处包装，例如：
- 将底层 IOException 转为业务级 ConfigLoadException（有意义的抽象）
- 其他中间层改用 e.addSuppressed(anotherEx)，不新增堆栈，只保留关联关系
- 若必须构造新异常又不需要原始堆栈，可用 new RuntimeException(msg).initCause(null)，跳过 fillInStackTrace()
日志输出必须做深度控制
并发报错时，logger.error("fail", e) 是内存和网络带宽的主要消耗源。全堆栈字符串可能达数 KB，千次并发就产生 MB 级日志体。
- Logback 中用 %ex{2} 限制最多输出 2 层堆栈（外层 + 内层）
- 对高频已知错误（如 RedisTimeoutException），只记录摘要："Redis timeout (key=xxx, ms=2000)"，不带堆栈
- 启用异步日志器（如 Log4j2 AsyncLogger），并设阻塞策略与队列上限，防打爆内存或线程阻塞
结构化并发中聚合异常而非拼接
用 StructuredTaskScope 或 CompletableFuture.allOf() 启动大量子任务时，不要让每个失败任务都抛出独立全栈异常。汇总后极易撑爆堆内存，连带序列化时带出巨量文本。
- 调用 scope.exceptionallyCompleted() 只取第一个失败原因
- 自定义 CompositeException：只存类名、消息摘要、错误计数，不存任何 StackTraceElement[]
- 批量异常上报做采样，如“每 1000 次失败上报 1 次全栈，其余仅计数+指标打点”
序列化前裁剪异常内容
只要异常要跨进程或落盘（如写入 Kafka、存入 Elasticsearch、传给前端），就必须清理掉非必要字段。
- 重写 writeObject() 或使用 Jackson 的 @JsonIgnore 注解，忽略 stackTrace、suppressedExceptions 字段
- 对 detailMessage 做长度截断（如 ≤512 字符），末尾加 "[truncated]" 标识
- 禁用 Throwable 默认序列化机制，改用轻量 JSON 结构：{ "type": "ServiceException", "msg": "...", "cause": "IOException" }
不复杂但容易忽略：带宽压力从来不在“抛异常”那一刻，而在“怎么记、怎么传、怎么存”这三步。控制住这三步，长描述和深堆栈就不再成为并发故障的放大器。
