Java中long字面量漏写L后缀会导致编译期整数溢出，因无后缀整数字面量默认按int解析（范围−2,147,483,648～2,147,483,647），超限即报“integer number too large”错误，必须显式写为xxxL才能被识别为long。
Java 中 long 字面量忘记加 L，表面看可能编译通过、运行无异常，但实际已埋下类型误判、数值截断或方法调用失败的隐患。这类 Bug 往往在边界值场景才暴露，排查时容易绕弯路。关键不是“怎么修”，而是“怎么快速定位它本就存在”。
看编译错误：最直接的线索
当字面量数值超过 int 最大值（2147483647） yet 未加 L，编译器会报错：
- “integer number too large” —— 这是明确信号：你写了一个超范围整数，却没告诉编译器它是 long
- 常见触发点：
9999999999、0x80000000、010000000000L（八进制）等，只要值 > 2147483647 或
查方法调用不匹配：隐性失败点
即使数值在 int 范围内，若目标方法参数是 long，而你传入无后缀字面量，看似能过编译（因自动拓宽），但一旦该值后续被用于计算或与其他 long 混合运算，就可能掩盖真实意图，更危险的是——
- 当方法重载存在
void process(int)和void process(long)时，process(100)会意外调用 int 版本，而非你预期的 long 版本 - 排查方式：在 IDE 中按住 Ctrl（Windows）或 Cmd（Mac）点击方法名，看跳转到哪个重载；或启用编译器警告（如
-Xlint:all），部分场景会提示“ambiguous method call”
盯住十六进制/八进制字面量：最容易忽略的盲区
开发者常以为“用了 0x 就是 long”，其实不然。编译器只看值是否超 int 范围，不看进制：
立即学习“Java免费学习笔记（深入）”；
-
0x7FFFFFFF✅ 是 int 最大值（2147483647），合法 -
0x80000000❌ 编译失败（值为 2147483648，超 int 上界）→ 必须写成0x80000000L -
017777777777（八进制）≈ 2147483647 → 刚好卡线；再加一位就溢出，必须补 L
统一代码规范：从源头杜绝
与其等 Bug 冒泡，不如建立防御习惯：
- 所有大于
Integer.MAX_VALUE或小于Integer.MIN_VALUE的整数字面量，强制加 L（大写） - 团队代码检查工具（如 SonarQube、Checkstyle）配置规则：检测无后缀且值 ≥ 2147483648 的整数字面量，标记为高危
- IDE 设置：启用 “Highlight long literals without suffix” 类似提示（IntelliJ 支持自定义 inspections）
