Numba 的 @njit 在 Python 3.11 中对大整数（如 94906267）执行 **2 运算时，会意外引入 int64 → float64 → int64 的隐式类型转换，导致结果被截断（如 9007199515875289 变为 9007199515875288），而纯 Python 或 Python 3.12+ 则无此问题。
numba 的 `@njit` 在 python 3.11 中对大整数（如 94906267）执行 `**2` 运算时，会意外引入 `int64 → float64 → int64` 的隐式类型转换，导致结果被截断（如 9007199515875289 变为 9007199515875288），而纯 python 或 python 3.12+ 则无此问题。
这个问题的本质并非用户代码错误，而是 Numba 在 Python 3.11 特定版本（如 0.61.0）中对幂运算 `的 LLVM 代码生成存在缺陷**：它将本应直接进行的int64 × int64乘法，错误地插入了sitofp（有符号整数转浮点）和fptosi（浮点转整数）指令，而float64仅能精确表示 ≤ 2⁵³ 的整数（约 9.007e15），而94906267² = 9007199515875289 > 2⁵³`，因此发生舍入误差。
✅ 可靠解决方案（推荐按优先级排序）：
-
避免 ``，改用显式乘法（最简单、最有效）**
from numba import njit @njit def safe_square(a): return a * a # ✅ 正确：直接 int64 乘法，无类型转换 result = safe_square(94906267) print(result) # → 9007199515875289（正确） -
升级 Python 和 Numba（长期根本解）
- 该问题已在 Python 3.12+ 和较新 Numba（≥0.62）中修复（LLVM 生成代码不再插入冗余浮点转换）。
- 验证方式：运行
f.inspect_llvm()，确认输出中仅有mul nsw i64 ...，无sitofp/fptosi指令。
-
显式指定返回类型并禁用自动类型推断（进阶）
@njit("int64(int64)") def square_explicit(a): return a ** 2 # ⚠️ 仍不推荐，仅作兼容性尝试；优先选 `a * a`注意：即使加签名，Python 3.11 下
**的底层实现缺陷仍可能触发，故乘法替代法仍是首选。
⚠️ 其他注意事项：
-
math.pow(a, 2)同样返回float，本质是float64运算，天然存在精度限制，绝不应用于需要精确整数结果的场景。 - 若需通用幂运算（如
a ** n, n > 2），务必用循环或np.power（配合dtype=np.int64）并验证溢出；对平方，永远首选a * a。 - 在性能敏感代码中，
a * a不仅更准确，通常也比a ** 2略快（省去幂运算解析开销）。
? 总结：@njit 下整数平方精度问题源于 Python 3.11 与旧版 Numba 的编译器协同缺陷。最稳健实践是彻底规避 `2，统一使用a * a`** —— 它语义清晰、性能优异、零精度风险，且完全兼容所有 Python/Numba 版本。
