13位时间戳字面量易致编译失败，因其超32位有符号整数上限2147483647；必须加LL/ULL后缀（如1712045678901LL）以明确64位类型，否则触发隐式截断、溢出或未定义行为。

时间戳字面量后缺失 l（或 ll、ull）后缀，会导致编译器按默认整型推断类型，可能在32位环境或严格类型检查下触发编译期整数溢出——这不是运行时错误，而是编译直接失败或产生隐式截断，后果更隐蔽。

为什么13位时间戳字面量容易爆编译

JavaScript 常用的毫秒级时间戳如 1712045678901 是13位十进制数，已远超32位有符号整数最大值 2147483647。若写成：

time_t t = 1712045678901;

编译器会尝试将其解释为 int 或 long（取决于平台），在多数32位或 ILP32 模型下，该字面量无法被合法表示，GCC/Clang 通常报错：integer constant is so large that it is unsigned 或 overflow in implicit constant conversion。

常见错误写法与对应风险

• int64_t ts = 1625902260000; → 缺 LL，字面量可能被当作 int 截断为低32位，实际存入 -2069797376
• #define JS_TS 1712045678901 → 宏展开后参与运算时，若上下文是 int 运算，立即溢出
• printf("%ld", 1712045678901); → 格式符与实际类型不匹配，未定义行为，可能打印乱码或崩溃

正确声明时间戳字面量的写法

• 用于 int64_t 变量：写成 1712045678901LL（推荐），明确要求 long long 类型
• 用于无符号64位：写成 1712045678901ULL，避免符号扩展问题，尤其在位运算或比较中更安全
• 宏定义中务必带后缀：#define JS_TS 1712045678901LL，否则宏一展开就失去类型保障
• 与除法结合时也需注意：(1712045678901LL / 1000) —— 若不加 LL，先以 int 计算再除，早已溢出

如何检测和规避这类问题

• 开启编译警告：-Wliteral-conversion（Clang）或 -Woverflow（GCC），能捕获字面量隐式降级
• 静态分析工具如 cppcheck --enable=style 可识别无后缀大整数赋值给64位变量
• 在构建脚本中加入检查：用正则扫描源码中形如 [0-9]{13,} 且后无 [ULL|LL|L] 的数字字面量
• 团队规范强制要求：所有 ≥10⁹ 的整数字面量必须显式标注后缀