java框架中基本类型与包装类的选择依据语义、空值需求、泛型约束和性能边界：泛型场景必须用包装类；api参数/返回值按是否允许null选型；缓存需警惕integer范围；包装类显式表达“未设置”。
Java 基本类型与包装类在框架源码中不是随意选用的，而是依据语义、空值需求、泛型约束和性能边界做明确区分。规范定义的核心不是“能不能用”，而是“该不该用”——框架作者必须让类型选择本身传递设计意图。
泛型容器场景：必须用包装类
所有基于 Collection、Map 或自定义泛型组件（如 Spring 的 BeanFactory、MyBatis 的 ParameterHandler）都强制要求类型参数为引用类型。基本类型无法作为泛型实参，编译直接失败：
-
List<integer></integer>✅ 合法，可存null，支持自动装箱 -
List<int></int>❌ 编译报错：“Type argument cannot be of primitive type”
框架源码中常见写法：public <t> T getBean(Class<t> requiredType)</t></t> —— 这里的 T 必然继承自 Object，所以传入 Integer.class 可行，int.class 不合法。
方法参数与返回值：按语义选型
框架 API 设计强调契约清晰。是否允许 null、是否表示“缺失值”或“未初始化”，直接决定类型选择：
- 配置项读取（如
Environment.getProperty("timeout", Integer.class)）→ 返回Integer，因为属性可能不存在，null是合法且有意义的状态 - 内部计算逻辑（如
AbstractBeanFactory.doGetBean()中的 hash 计算、索引偏移）→ 使用int，避免空指针且无意义为空 - 数据库映射层（如 MyBatis 的
TypeHandler<integer></integer>）→ 包装类，因 JDBCResultSet.getObject()可返回null，对应字段允许为 NULL
缓存与常量池：注意 Integer 等的缓存边界
框架大量使用 valueOf() 替代 new，既复用对象又规避 NPE。但需警惕缓存范围（如 Integer 默认 -128 ~ 127）：
- Spring 的
NumberUtils工具类中，parseNumber(..., Integer.class)返回的是缓存内或新创建的Integer实例 - 比较时禁用
==判断数值相等：if (statusCode != HttpStatus.OK.value())→ 正确；if (statusCode == HttpStatus.OK.value())→ 若值超出缓存范围，可能因对象不等而误判 - 源码中统一用
.equals()或拆箱后比较：Objects.equals(a, b)或a.intValue() == b.intValue()
默认值与初始化策略：包装类显式表达“未设置”
基本类型有隐式默认值（int=0, boolean=false），易掩盖业务含义；包装类的 null 是主动信号：
- Spring Boot 的
@ConfigurationProperties类中，字段声明为private Integer port;表示“端口未配置时保持 null”，而非默认 0（非法端口） - Jackson 反序列化时，JSON 中缺失字段 →
Integer字段为null，int字段强制为 0，后者可能引发误判 - 框架启动校验逻辑（如
AbstractRefreshableApplicationContext）会检查关键包装类字段是否为null，触发 early fail-fast
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
