Java中时间戳字面量漏写L后缀会编译失败，因为无后缀十进制整数字面量默认按int解析（范围−2,147,483,648～2,147,483,647），而毫秒级时间戳（如1712045678901）远超该范围，触发“integer number too large”编译错误；必须显式写为1712045678901L才能被识别为long。
Java 中时间戳字面量若为 long 类型却漏写 L 后缀，会直接触发编译期整数溢出错误——这不是运行时异常，而是编译器在词法/语法分析阶段就拒绝通过。关键在于：它本质是类型误判，而非计算溢出。
为什么时间戳字面量不加 L 就会编译失败
Java 规定所有无后缀的十进制整数字面量（如 1712045678901）默认按 int 解析，取值范围仅限 −2,147,483,648 ～ 2,147,483,647。而毫秒级时间戳（例如 2024 年之后的）早已突破该上限：
-
1712045678901→ 编译报错：integer number too large -
1712045678901L→ 正确识别为long，顺利通过编译
常见被忽略的“合法但危险”场景
有些字面量看似没超 int 范围，但用在 long 上仍建议加 L，否则易埋隐患：
- 方法参数为
long，调用时传f(2147483647)可行，但f(2147483648)必须写成f(2147483648L)，否则编译失败 - 十六进制或八进制时间戳（如
0x18B4E5C0000L或01712045678901L）同样需显式加 L；0x80000000会编译失败，必须写0x80000000L - 使用大写 L（非小写
l），避免与数字1混淆，如1672531200000L✅，1672531200000l⚠️
错误写法如何引发隐蔽逻辑问题
以下代码看似只是“少写一个字母”，实则破坏语义和可维护性：
-
long t = 1672531200000;→ 编译失败，无法构建 -
long t = (long) 1672531200000;→ 仍失败！因为括号内先按 int 计算，已溢出，再转 long 也于事无补 - 正确写法只有一种：
long t = 1672531200000L;（注意 L 在数字末尾）
工程实践建议
统一规范能从源头杜绝此类问题：
- 所有超过 10 位的整数字面量，只要用于时间戳、ID、大计数等场景，一律加 L
- IDE 配置检查规则（如 SonarQube、Checkstyle），对缺失 long 后缀的字面量发出警告
- CI 流程中启用
-Xlint:all编译选项，捕获潜在类型推断问题
