改字段类型不等于“省网卡带宽”，因为网卡带宽消耗取决于序列化后字节流大小、传输频次和协议开销；包装类转基本类型主要降低内存占用、避免装箱/空值判断、减轻gc压力，从而间接提升吞吐量，为序列化优化（如精简payload、启用gzip）提供稳定基础。
直接将包装类字段改为基本类型，对网卡带宽没有直接影响。网卡带宽消耗取决于序列化后字节流的大小、传输频次和网络协议开销，而包装类与基本类型的差异主要体现在 JVM 内存布局与对象创建行为上——它影响的是序列化前的对象体积、GC 压力和 CPU 序列化耗时，间接作用于单位时间可处理的数据吞吐量。
为什么改字段类型不等于“省网卡带宽”
网络带宽是物理层/传输层概念，衡量单位时间通过网卡的数据量（如 MB/s）。DTO 对象本身不走网卡；只有它被序列化成字节（如 JSON、Protobuf）、经 socket 发送时，才产生网络流量。因此真正影响带宽的是：
- 序列化格式的紧凑程度（如用 Protobuf 替代 JSON 可减少 60%+ 字节数）
- 字段是否为 null 导致额外标记（如 JSON 中 "age":null 比 "age":25 多传 7 字节）
- 对象实例数量与频率（每秒 10 万次序列化 × 每次多 24 字节 = 额外 2.4 MB/s 带宽）
- JVM 堆内对象膨胀引发 GC 暂停，拖慢整体吞吐，造成“看似带宽不足”的假象
包装类转基本类型的真实收益点
在海量 DTO 场景下（如日均亿级订单明细传输），把 Integer age 改成 int age 的核心价值不在“减网卡”，而在以下三处：
- 内存占用下降：Integer 是堆中对象（含对象头、Mark Word 等），至少 16 字节；int 固定占 4 字节栈空间。100 万个 DTO 实例，仅 age 字段就节省约 12 MB 堆内存
- 避免空指针与装箱开销：JSON 序列化库（如 Jackson）遇到 Integer 会检查是否为 null，再决定写 "null" 或数值；而 int 默认值 0，直接输出数字，无分支判断、无 null 检查，CPU 更高效
- 降低 GC 压力：大量短生命周期 Integer 对象触发 Young GC 频率上升，暂停时间增加，间接拉低服务吞吐能力 —— 吞吐降了，单位时间发包数减少，自然“显得”带宽没跑满
配套必须做的序列化优化动作
单改字段类型效果有限，需组合落地才能看到带宽相关指标改善：
- 启用 Jackson 的 WRITE_NULLS=false：全局关闭 null 字段输出，避免传输冗余字符串
- 用 @JsonInclude(JsonInclude.Include.NON_DEFAULT)：让 int/boolean 等基本类型默认值（0/false）也不序列化，进一步压缩 payload
- 切换序列化协议：从 JSON 换为 Protobuf 或 FlatBuffers，字段名不传、类型编码更紧凑，实测 DTO 体积常缩小 50–80%
- 开启 GZIP 压缩（HTTP 层）：对文本类序列化结果压缩率可达 70%，比改字段类型带来的收益更显著
一个真实对比示例
某电商订单 DTO 含 12 个数字字段（price、qty、discount 等），原全部用包装类：
- JSON 序列化后平均 328 字节/条（含 null 字段和引号、冒号等）
- 改为基本类型 + NON_DEFAULT + 关闭 WRITE_NULLS 后，降至 192 字节/条
- 叠加 GZIP 压缩（典型 3:1），最终网络传输仅约 64 字节/条
- 10 万 TPS 场景下，原始带宽占用 ≈ 106 MB/s，优化后 ≈ 62 MB/s，下降 41%
这里带宽下降的主因是 payload 压缩与精简，字段类型重构是支撑该优化能稳定运行（不报 NPE、不异常扩量）的基础保障。
