std::numeric_limits::digits10 不可靠，因 long double 在 linux x86_64（≈19）与 windows msvc（=15）精度差异达4位；应实测、弃用 long double 跨平台、避免硬编码浮点阈值。
std::numeric_limits::digits10 不可靠
不同平台对 long double 的实现差异极大：Linux x86_64 上通常是 80 位扩展精度（digits10 ≈ 19），而 Windows MSVC 中常退化为 64 位 double（digits10 = 15）。这意味着同一段代码在 CI 构建机（Linux）和本地 Windows 开发环境里，long double 实际能提供的十进制精度可能差 4 位。
不要依赖 sizeof(long double) 或 std::numeric_limits<long double>::max()</long> 来判断精度——它们只反映存储大小或范围，不等于有效位数。
- 用
std::numeric_limits<long double>::digits10</long>前，先在目标平台实测输出值 - 若需跨平台一致精度，直接放弃
long double，改用double+ 显式误差控制 - CI 配置中应强制指定平台（如
-D_WIN32或__linux__），避免误判
浮点比较阈值不能硬编码 1e-9
1e-9 对 float 太松（float 仅 6–7 位有效数字），对大数值的 double 又太紧（相对误差会随数值增大而放大）。例如 1e12 + 1.0 == 1e12 在 double 下恒为 true，此时 abs(a-b) 完全失效。
更稳妥的做法是结合绝对误差和相对误差：
- 小数值（
abs(a) ）用绝对容差：<code>abs(a - b) - 大数值用相对容差：
abs(a - b) - 或统一用
std::abs(a - b) ::epsilon() * std::max(std::abs(a), std::abs(b))
std::setprecision 只影响输出，不修复计算误差
很多人调了 std::setprecision(2) 后看到 <code>0.30 就以为“精度问题解决了”，其实内部值仍是那个不等于 0.3 的二进制近似值。后续所有计算仍基于这个误差值继续累积。
真正需要控制显示时，优先显式舍入：
-
std::round(x * 100.0) / 100.0（注意：这本身引入新误差，仅用于最终展示） - 调试时用
printf("%.17g", x)查看真实存储值，%g会暴露尾部隐藏数字 - 金融等场景必须规避浮点：用
int64_t存“分”，所有运算在整数域完成
跨平台计时精度差异直接影响误差容忍度
高精度定时器返回的时间值本身就有平台级分辨率差异：QueryPerformanceCounter 在 Windows 上典型最小分辨率为 ~100 纳秒，而 clock_gettime(CLOCK_MONOTONIC) 在 Linux 上可达 1 纳秒。如果你用定时器结果做浮点差值比较（比如判断某操作是否超时），这个底层分辨率差异会直接放大浮点误差。
推荐统一使用 std::chrono::steady_clock：
- 它自动对接各平台最优 API，屏蔽底层差异
- 返回的是
std::chrono::duration，避免手动除法引入浮点误差 - 比较时用
duration_cast<:chrono::milliseconds>(t)</:chrono::milliseconds>转整数，而非转double秒
平台差异最狡猾的地方，往往不在你写的代码里，而在你没意识到的隐含假设中——比如默认所有平台的 long double 都一样，或者认为 1e-9 是通用安全阈值。这些假设一旦跨平台就容易崩。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
