std::lcm 和 std::gcd 在 C++17 中标准化，需包含 且参数为可转换为 common_type_t 的整型；gcd 对负数取绝对值，gcd(0,0) 未定义；lcm 易因中间乘法溢出，建议先除后乘并检查零值。
std::lcm 和 std::gcd 在 C++17 中已标准化，但直接使用需满足两个硬性前提：编译器支持 C++17 且包含 <numeric></numeric> 头文件；传入参数必须是**可转换为 std::common_type_t<t u></t> 的整型（非浮点、非指针、非类类型）**，否则编译失败。
std::gcd 要求两个参数都为正整数？
不准确。std::gcd 实际上接受**任意有符号或无符号整型值，但会先取绝对值再计算**。若任一参数为 0，结果是另一个参数的绝对值（即 gcd(a, 0) == abs(a)）。传入负数不会报错，但结果恒为非负整数。
常见错误现象：
- 传入
0和0→ 编译通过，但行为未定义（C++ 标准明确指出gcd(0, 0)是未定义行为，GCC/Clang 通常返回 0，但不可依赖） - 传入
int和long long→ 若int值超出long long表示范围（极罕见），可能隐式转换溢出；更常见的是因类型不匹配导致模板推导失败
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 显式转换为同一有符号整型，如
std::gcd(static_cast<long long>(a), static_cast<long long>(b))</long></long> - 避免
gcd(0, 0)，加运行时检查：if (a == 0 && b == 0) throw std::invalid_argument("gcd(0, 0) is undefined");
std::lcm 编译失败的常见原因
最常被忽略的是：std::lcm 内部调用 std::abs 和 std::gcd，并做乘法 abs(m) / gcd(m, n) * abs(n)。这意味着：
- 若乘法
abs(m) * abs(n)溢出（即使最终除以 gcd 后不溢出），整个表达式在计算中间步骤就已溢出 → 未定义行为 - 参数类型必须支持
/和*运算符，且结果能隐式转为目标公共类型；unsigned char和short可能因整型提升规则导致推导出int，但若原始值较大（如USHRT_MAX），仍可能溢出 - MSVC 2019 16.10+ 才完全支持
std::lcm；GCC 7+、Clang 7+ 支持，但需确保开启-std=c++17（不是c++1z）
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对大数使用
long long或__int128（GCC/Clang 扩展）并手动实现 lcm 防溢出：long long safe_lcm(long long a, long long b) { if (a == 0 || b == 0) return 0; long long g = std::gcd(a, b); return (a / g) * abs(b); // 先除后乘，降低溢出概率 } - 检查编译器版本和标准：用
__cplusplus宏验证：#if __cplusplus
与 Boost.Math 或自定义实现的性能差异
std::gcd 使用二进制 GCD（Stein 算法）或硬件指令优化（如 x86 的 __builtin_ctz），在多数现代 STL 实现中比朴素欧几里得递归快 10%–30%；std::lcm 无额外算法优化，纯属包装，性能取决于 std::gcd 和乘除开销。
关键影响点：
- 启用
-O2或更高优化级时，std::gcd常被内联为 5–10 条汇编指令；未优化时可能生成函数调用开销 - Boost.Math 的
boost::math::gcd接口兼容旧标准，但无 C++17 的类型约束（SFINAE），错误提示更模糊 - 手写欧几里得循环版（
while (b) { auto t = b; b = a % b; a = t; }）在小整数场景下与std::gcd性能几乎一致，但丢失对大整数和边界值（如INT_MIN）的健壮处理
最容易被忽略的点是：std::lcm 和 std::gcd **不支持浮点类型，也不支持用户自定义整数类**——哪怕该类重载了 % 和 /。它们只接受原生整型或满足 std::is_integral_v<t></t> 的类型。想用于大整数库（如 boost::multiprecision::cpp_int），必须自己实现，不能直接套用标准函数。
