基本类型与包装类是契约表达的底层载体：基本类型隐含“必填非空”，如pageNum用int；包装类明示“可选可空”，如status用Integer；DTO中ID、金额等须用Long、BigDecimal，禁用float/double；泛型集合强制引用类型，List<Integer>合法而List<int>编译失败。
在架构设计中，基本类型与包装类不是语法细节，而是契约表达的底层载体。选错类型，等于在接口上埋下歧义、空指针或兼容性隐患。关键不在“能不能用”，而在“为什么这样用”——每种选择都应服务于明确的语义契约。
参数是否允许缺失：用包装类声明可选性
接口方法的参数是契约的第一道语言。基本类型（如 int、boolean）天然隐含“必须提供且非空”的语义；而包装类（如 Integer、Boolean）则明示“该值可不传、可忽略、可过滤”。这不是技术妥协，而是设计意图的显式表达。
- 分页查询中 pageNum 和 pageSize 用 int —— 它们是协议必需字段，缺一不可
- 状态筛选字段 status 用 Integer —— null 表示“不限状态”，0 或 1 才表示具体值，语义清晰无歧义
- 禁止将包装类型参数用于强制必填场景（如 public void createOrder(Long userId)），否则调用方需额外判空，违背契约直觉
DTO 与领域模型中的字段定义：按语义而非便利选型
数据传输对象（DTO）和领域实体中的字段类型，直接影响序列化行为、JSON 兼容性及下游解析逻辑。这里要区分“存储需求”和“契约需求”：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- ID 字段统一用 Long（包装类）：即使数据库主键为 BIGINT，也避免用 long 基本类型，否则 Jackson 反序列化 null 时抛 JsonMappingException
- 金额、数量等业务数值字段优先用 BigDecimal（非基本/包装类，但属契约首选）；若确需用基本类型，仅限内部计算层，对外 DTO 中禁用 float/double —— 它们无法精确表达货币，违反金融类契约可靠性
- 布尔标识如 isDeleted，DTO 中用 Boolean，便于前端传
null表示“未指定删除状态”；实体类中可转为 boolean（默认 false），由构造或 Builder 控制赋值逻辑
泛型与集合约束：包装类是唯一合法入口
Java 泛型擦除机制决定了：所有集合（List、Map、Optional）只能容纳引用类型。基本类型无法直接入参或作为泛型实参——这不是限制，而是强制你把“值的语义”提升为“对象的契约”。
立即学习“Java免费学习笔记（深入）”；
- List<Integer> 是标准契约；List<int> 编译失败，提醒你此处必须考虑 null 安全与边界含义
- 使用 Optional<Integer> 显式表达“可能无值”的返回契约，比返回 int 并约定 -1 为无效值更可靠、更易测试
- 自定义泛型工具类（如 Result<T>）中，T 必然对应包装类或其子类，迫使你在设计阶段思考“空值如何传播”“异常如何封装”
协议适配与跨系统交互：类型决定字节级兼容性
当服务对接 HTTP、MQ、二进制协议或数据库时，基本类型与包装类在序列化链路中扮演不同角色：
- 使用 ByteBuffer 解析定长报文时，getInt() 返回的是 int，这是性能敏感路径的合理选择；但该值一旦进入业务逻辑层，应尽快封装为领域对象字段（如 OrderId 类型），避免裸基本类型污染契约边界
- JSON 接口接收 "count": null，Jackson 默认将 Integer count 字段设为 null；若字段声明为 int count，则反序列化直接失败或静默归零，掩盖真实业务意图
- 数据库 ORM 映射中，整数列映射为 Integer 更安全——NULL 值可自然映射，而 int 会触发默认值填充（如 0），导致“数据丢失却无感知”
