java基本类型误用是线上问题主因，需严守四原则：禁用null比较、金额用bigdecimal、警惕装箱拆箱陷阱、按语义选型。

Java 基本数据类型看似简单，但实际开发中大量线上问题都源于对它们的误用。关键不是“会不会写”，而是“是否清楚它的边界、默认行为和隐式规则”。下面从四个高频出错场景出发，给出可直接落地的规避方式。

别拿基本类型跟 null 比较或赋值

int、long、boolean 等基本类型在栈上直接存值，根本不能为 null。一旦写成 if (count == null) 或 Integer id = null; int rawId = id;，前者编译报错，后者运行时抛 NullPointerException。

• 需要表达“可能为空”的语义时，统一用包装类（Integer、Long、Boolean）
• 从数据库或 JSON 解析拿到的数值字段，如果源端允许为空，接收变量必须声明为包装类型
• 做非空判断时，用 Objects.nonNull(x) 或显式判 x != null，而不是依赖自动拆箱

金额、精度敏感场景禁用 float/double

浮点数在二进制下无法精确表示十进制小数，0.1 + 0.2 != 0.3 是常态。订单金额、财务统计、积分计算等场景一旦用 double 存储或参与运算，误差会累积放大。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 金额统一使用 BigDecimal，构造时用字符串入参（new BigDecimal("19.90")），避免 double 构造器
• 如需高性能且精度要求不高（如埋点统计），可用 long 存“分”单位，全程整数运算
• 绝对不要在循环中对 float 累加——误差随次数线性增长

注意自动装箱/拆箱的缓存与空指针陷阱

Integer.valueOf(127) 返回的是常量池对象，而 Integer.valueOf(128) 每次新建；同时，任何包装类变量只要为 null，一拆箱就崩。

• 比较两个 Integer 是否相等，用 Objects.equals(a, b) 或 a.equals(b)，禁止用 ==
• 方法参数或返回值若声明为包装类型，入口处先校验非空，或用 @NonNull 注解约束
• 集合中存数字，如 List<integer></integer>，遍历时避免直接用基本类型接收（int x : list 可能触发隐式拆箱）

选型要匹配业务语义和取值范围

不是“越大越安全”，而是“够用且不易溢出”。比如用户 ID 用 int，当达到 21 亿后就会翻转为负数；而日志序列号用 short，稍大一点就溢出。

• 计数器、数组下标、普通 ID → int（日常最稳妥）
• 时间戳、分布式主键、大数据量统计 → long（带 L 后缀写死）
• 协议字段、IO 缓冲区字节 → byte（注意它是有符号的，-128~127）
• 单个字符存储 → char（2 字节，UTF-16，不是 ASCII）
• 开关、状态位 → boolean（不要用 int 存 0/1，语义不清且浪费空间）

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南