c++23 之前必须手写梯形法；即使 c++23 也因编译器支持不全、仅限 std::span/可调用对象、不支持变步长等限制，95% 场景仍需手动实现，循环应从 i=0 到 n-1，每步累加 (y[i]+y[i+1])*h/2。
用 std::trapezoidal 还是自己写？C++23 之前没这个函数
别被名字骗了——C++23 标准库确实新增了 std::trapezoidal，但主流编译器（GCC 13/Clang 17）默认不启用 C++23 完整支持，且它只接受 std::span 和可调用对象，不处理自定义步长或非等距点。实际项目里，95% 的情况得手写或靠第三方库。
常见错误现象：std::trapezoidal 编译失败、链接不到符号、或者传入 raw 指针被拒绝。不是你写错了，是标准还没落地。
- 如果已确定用 C++23 且编译器支持完整特性（需加
-std=c++23 -fexperimental-library），才考虑它 - 否则老实用
for循环实现梯形法，逻辑清晰、调试方便、无依赖 - 注意：C++23 版本不支持变步长，遇到实验数据点不等距时照样得绕开
手动实现梯形法时，i 从 0 还是 1 开始循环？边界怎么处理
核心就一条：积分区间 [a, b] 被拆成 n 段，对应 n+1 个点。循环变量必须覆盖全部分段，但不能重复算端点。
典型错误：用 for (int i = 0; i 却把 <code>f(x[i]) + f(x[i+1]) 全加进去，导致中间点被算了两次；或者漏掉最后一段。
立即学习“C++免费学习笔记（深入）”；
- 推荐写法：
double sum = 0.5 * (f(x[0]) + f(x[n]));先加两端，再for (int i = 1; i - 若用步长
h和起始值a动态生成点，务必用x[i] = a + i * h，避免浮点累积误差（比如不用x[i] = x[i-1] + h） - 当
n很大时，sum累加顺序影响精度，建议用 Kahan 求和——但多数工程场景不需要
用 boost::math::quadrature 会比手写快吗？什么情况下值得引入
Boost.Math 的 gauss_kronrod 和 adaptive_simpson 是真·工业级实现，但“快”不是指单次调用耗时，而是指达到同等精度所需的函数求值次数更少。
容易踩的坑：它默认要求被积函数是 double(double)，不接受捕获 Lambda（除非包装成函数对象）；且对奇点、震荡函数（如 sin(1/x) 在 0 附近）可能收敛失败，报错信息是 boost::exception_detail::clone_impl<...></...>，看不出问题在哪。
- 适合场景：被积函数计算代价高（如涉及矩阵运算）、需要 1e-12 级精度、或积分限含参数需反复调用
- 不适合场景：简单多项式、实时性要求严苛（启动开销明显）、构建环境禁止 Boost
- 配置项关键点：
max_depth控制递归深度，默认 10 太保守，复杂函数要设到 15–20；tolerance建议设为1e-9而非1e-15，后者易触发最大深度退出
数值积分结果不准，该先查 f(x) 还是查 n？
80% 的精度问题出在被积函数本身，而不是划分太粗。尤其当 f(x) 在区间内有突变、未定义点、或返回 NaN 时，梯形法会直接传播错误。
一个常被忽略的事实：即使 n = 1000000，只要 f(0.5) 返回 inf，整个结果就是 inf。而人眼很难从最终数字反推哪个 x 出了问题。
- 第一步永远是对
f(x)做采样检查：取 10–20 个等距点，打印x和f(x)，确认没有nan、inf、过大绝对值 - 第二步再看
n是否足够：固定n，改用辛普森法对比；若两者结果差很多，说明函数曲率大，梯形法本身就不适用 - 特别注意：如果
f(x)内部调用了std::sqrt或std::log，检查输入是否越界——这比调大n有用十倍
事情说清了就结束。最麻烦的永远不是公式怎么写，而是 f(x) 在某个没人想到的 x 上悄悄崩了。