将integer改为int不能直接缩减网卡带宽，而是通过减少堆内存、降低gc频率、加速jackson序列化、剔除默认值字段来提升吞吐量，需同步配置non_null/non_default及换用protobuf等紧凑协议。
直接改 integer age 为 int age 并不能“缩减网卡带宽”。
网卡带宽消耗取决于序列化后的字节流大小、传输频次和协议开销，而 int 和 Integer 在 JVM 内存中属于不同层级的结构：前者是栈上固定4字节值，后者是堆上至少16字节的对象。它们的差异不体现在网络报文里，而体现在序列化前的对象构建、CPU处理效率和GC行为上。
所以真正起作用的链条是：
- 基本类型 → 更少堆内存 → 更低 GC 频率 → 更稳的吞吐能力
- 基本类型 → 无 null 判断 → Jackson 序列化更快 → 单位时间可处理更多请求
- 基本类型 → 默认值确定（如
0、false）→ 配合@JsonInclude(NON_DEFAULT)可精准剔除冗余字段
关键不是“省带宽”，而是让带宽跑得更满
当服务因 GC 暂停或序列化卡顿导致每秒只能发 5 万条消息时，即使 payload 少了 10 字节，实际带宽利用率也上不去。把 Integer 换成 int，配合正确配置，才能释放出原本被拖慢的吞吐潜力。
必须同步做的三件事
-
关闭 null 字段输出：全局设
mapper.setSerializationInclusion(JsonInclude.Include.NON_NULL)或WRITE_NULLS = false，避免"age":null多传 7~9 字节 -
剔除默认值字段：对
int/boolean等加@JsonInclude(JsonInclude.Include.NON_DEFAULT)，让{"age":0}不出现，只传业务上真正变化的值 - 换更紧凑的序列化协议：JSON 改 Protobuf 或 FlatBuffers，单对象体积常降 50%~70%，这才是直接影响带宽的杠杆
哪些地方适合改？哪些不该动？
- 适合改：DTO 类、RPC 请求/响应体、MQ 消息载荷、缓存 value —— 这些直面外部输入，空值语义明确（如“未填年龄”就该是 0，而非 null）
-
不该乱改：数据库实体类若字段有
@Column(nullable = false)+ DB 层强约束，保留int没问题；但若该字段在 DB 中允许 NULL，就必须用Integer，否则 ORM 反序列化时会静默填 0，造成数据失真
别指望单靠改类型见效
100 万个 Integer 对象比 int 多占约 12 MB 堆内存，这能缓解 Young GC，但不会让网卡少传 1 字节。真正的带宽优化来自：精简序列化 payload、压缩传输（GZIP）、减少不必要的字段、控制调用频次。字段类型重构只是让这些优化能稳定落地的底层支撑。
不复杂但容易忽略。
