__int128最快但仅限GCC/Clang非Windows平台；boost::multiprecision::int128_t跨平台但性能低10%–30%，需显式包含头文件并注意接口差异。
用 __int128 最快，但只在 GCC/Clang 且非 Windows 下可用
如果你的目标平台是 Linux/macOS + GCC 或 Clang（≥4.6），__int128 是最轻量、零开销的方案。它不是标准 C++ 类型，但编译器原生支持加减乘除、位运算、比较，甚至能用 printf 配合 %.39Ld（需手动拆成高低 64 位）输出。
常见错误是直接在 Windows MSVC 下尝试——它完全不识别 __int128，编译报 error: '__int128' was not declared in this scope；另一个坑是误以为它支持 std::cin >> 或 std::to_string，其实都不行，必须自己实现字符串转换。
- 启用条件：
-std=gnu++17或更高，不需额外头文件 - 判断是否可用：
#ifdef __SIZEOF_INT128__ - 不能取地址：
&x编译失败，也不能作为std::vector元素（因无默认对齐保证） - 乘法溢出不抛异常，结果是模 2¹²⁸，需业务层自行检查（比如先用
__builtin_mul_overflow）
跨平台时选 boost::multiprecision::int128_t，但注意头文件和链接
Boost.Multiprecision 的 int128_t 是最接近“开箱即用”的跨平台方案，底层在支持 __int128 时自动代理，否则回退到 4×32 位数组模拟，接口与原生整数高度一致。
容易踩的坑是只 #include <boost></boost> 却没意识到：这个头文件默认启用的是任意精度 cpp_int，不是固定 128 位。必须显式包含 <boost></boost> 并使用 boost::multiprecision::int128_t。
立即学习“C++免费学习笔记（深入）”；
- 不依赖 Boost 库链接，纯头文件，但需定义
BOOST_MULTIPRECISION_CPP_INT_BACKEND_HPP等宏时小心顺序 - 性能比原生
__int128低 10%–30%，尤其在频繁乘除场景（因有分支判断和内存访问） - 支持
std::ostream ，但输入仍需 <code>boost::multiprecision::read_json或手动解析字符串 - Windows + MSVC 下可用，但需关闭
/Zc:__cplusplus（否则__cplusplus宏值错误导致 SFINAE 失败）
手写 128 位类时，别直接拼 2×64 位——得处理进位链和符号逻辑
自己实现 struct int128 { uint64_t lo, hi; } 看似简单，但加减法里进位/借位传播、乘法中 64×64→128 的四次部分积叠加、除法的试商逻辑，全是易错点。更麻烦的是符号：用补码表示时，-1 是 0xffffffffffffffff, 0xffffffffffffffff，而 ~x + 1 手动实现极易漏掉跨字边界进位。
一个典型错误是写乘法时只算 lo * lo 和 hi * hi，忽略交叉项 lo * hi 和 hi * lo——它们各贡献一个 128 位中间结果，必须左移 64 位后累加。
- 加法关键代码片段：
uint64_t sum = lo + other.lo; hi += other.hi + (sum - 右移操作要区分算术右移（带符号）和逻辑右移（无符号），
>>对负数行为由实现定义，应改用static_cast<int128>(...).as_signed() >> n</int128>封装 - 避免在循环内反复构造临时对象，把
operator+声明为noexcept并用constexpr优化常量表达式 - 测试必须覆盖边界值：
INT128_MAX、INT128_MIN、-1、1ULL
性能敏感场景下，优先用编译器内置函数而非通用大数库
如果你的代码里 128 位运算集中在几个 hot loop（比如哈希计算、密码学轮函数），调用 GMP 或 OpenSSL 的 BN_add 这类通用大数接口会引入函数调用开销、内存分配、冗余校验，实测比 __int128 慢 5–10 倍。这些库设计目标是任意精度，不是固定宽度。
真正需要“高性能”时，得接受妥协：放弃 Windows 兼容性换速度，或用 if constexpr 在编译期分发路径（GCC 下用 __int128，MSVC 下用 Boost 回退）。
- 禁用 RTTI 和异常（
-fno-rtti -fno-exceptions）可让__int128运算进一步提速 2%–3% - 避免将
__int128存入std::map或std::unordered_map——哈希函数得自己写，且标准容器没针对它优化对齐 - Clang 下
__int128的popcount可用__builtin_popcountll(hi) + __builtin_popcountll(lo)，比循环查 bit 快一个数量级
实际项目里，128 位运算的“高性能”往往卡在 I/O 和类型转换上，而不是算术本身。别花时间优化除法算法，先确认你真的需要每次运算都走 128 位路径——很多时候用两个 64 位变量分段处理，配合 careful overflow check，反而更稳更快。
