最推荐使用 std::numbers::pi（c++17+），其次为 4.0 * std::atan(1.0) 或 std::acos(-1.0)；避免手写字面量、误用整数参数、/fp:fast 优化及低精度类型。
用 std::atan 或 std::acos 直接获取双精度 PI 值
多数场景下，你根本不需要自己算 PI——标准库早有现成、可靠、符合 IEEE 754 的近似值。C++17 起，std::numbers::pi 是最干净的写法；C++17 之前，4.0 * std::atan(1.0) 或 std::acos(-1.0) 是通用且跨平台的选择。
常见错误是手写 3.14159265358979323846 这类字面量：容易抄错、不明确精度来源、不同编译器对长字面量处理可能不一致。
-
std::numbers::pi是 constexpr，编译期求值，零开销 - 用
std::atan(1.0)时务必传1.0（double），别传1（int），否则可能触发重载歧义或隐式转换损耗 - Windows MSVC 在 /fp:fast 模式下可能优化掉
std::acos(-1.0)的精确性，建议关闭该选项或改用std::numbers::pi
需要更高精度时，别手写级数——用 boost::multiprecision
如果真要算到小数点后 1000 位，自己实现 Chudnovsky 或 Machin 公式极易出错：整数溢出、中间结果截断、收敛判断不稳、除法精度丢失……这些坑比算法本身更耗时间。
boost::multiprecision::cpp_dec_float_100 这类类型专为高精度浮点设计，底层已处理进位、舍入、异常检测，且与标准数学函数（如 boost::multiprecision::atan）配套。
立即学习“C++免费学习笔记（深入）”；
- 别用
long double强撑——它在 x86-64 Linux 是 80-bit 扩展精度，但 Windows MSVC 下只是 64-bit，行为不一致 - Chudnovsky 公式虽快，但阶乘和幂运算在大数下极慢；
boost内置的atan已针对cpp_dec_float优化过泰勒/AGM 混合策略 - 初始化时显式指定精度，比如
cpp_dec_float_100 pi = 4 * atan(cpp_dec_float_100("1"));，避免从低精度double隐式提升
自实现级数法（如 Leibniz 或 Machin）只适合教学验证
Leibniz 级数（4*(1 - 1/3 + 1/5 - 1/7 + ...)）收敛极慢：算 100 万项才勉强到小数点后 5 位。它唯一价值是帮你理解浮点累加误差怎么滚雪球。
如果你非得跑一遍，注意三个实际卡点：
- 循环变量用
size_t或uint64_t，别用int——1000 万次迭代就溢出 - 累加器必须用
long double或更高精度类型，float在第 10 万项后基本不更新了 - 别用
i % 2 == 0判断正负号——分支预测失败+整数模运算慢，改用sign = -sign更稳
编译期计算 PI？constexpr 有限制，别硬刚
C++20 的 constexpr 数学函数（如 std::sqrt）仍不包括 std::atan 或 std::acos，所以 std::numbers::pi 是目前唯一可信赖的编译期 PI 来源。
试图用模板递归展开 Machin 公式，会迅速撞上编译器递归深度限制（Clang 默认 256，GCC 900），而且编译时间爆炸，生成代码体积不可控。
- 若需编译期常量，老老实实用
std::numbers::pi（C++20）或宏定义PI_V（C++17 及以前） - 自定义
constexpr函数想调std::atan？不行——它不是字面量函数，编译器直接报错call to non-constexpr function - 用
consteval强制编译期求值？同样受限于标准库函数是否标记为consteval，目前没有
真正难的不是“怎么算”，而是搞清你需要的精度边界、运行环境约束、以及是否真的需要动用高精度库——多数 bug 出在误判需求，而不是算法写错。
