std::vector更安全易维护，但对接LAPACK/BLAS或高性能场景时裸指针可避免元数据开销与对齐不确定性；关键在生命周期可控，否则易致内存错误。
为什么不用 std::vector 而要用裸指针做多项式系数存储？
多数数学建模场景下，std::vector 更安全、更易维护；但当你需要和底层数值库（如 LAPACK、BLAS）对接，或在嵌入式/高性能计算中反复分配固定长度的系数数组时，裸指针能避免容器元数据开销与内存对齐不确定性。关键不是“用不用指针”，而是是否控制了生命周期——常见错误是 delete[] 忘记、浅拷贝导致双重释放，或传入 C 风格 API 前未确保连续内存布局。
- 仅当明确需与
dgemv、polyval（C 接口版）等函数交互时，才用double*管理系数 - 系数按升幂排列（
p[0]是常数项），否则 FFT 卷积或求导逻辑会错位 - 永远用
new double[n]{}初始化（带花括号清零），避免未定义值干扰数值稳定性
operator+ 和 operator* 重载里怎么处理不同阶数的多项式？
加法必须对齐阶数：低阶多项式高位补零；乘法则直接生成 deg(A)+deg(B) 阶结果。裸指针实现时，不能原地修改右操作数，必须分配新内存。容易踩的坑是忘记设置新数组长度，或用 memcpy 复制时长度单位错用字节数而非元素个数。
- 加法示例：
Polynomial a(3); // x²+2x+1 → a.coeffs = new double[3]{1,2,1}；Polynomial b(2); // 3x+4 → b.coeffs = new double[2]{4,3}；则a+b需分配new double[3]，并让b的高阶系数视为 0 - 乘法必须动态计算长度：
result_size = this->degree + other.degree + 1（+1 因为 0 阶存在） - 禁止返回局部指针：
return Polynomial(temp_ptr, temp_len)中temp_ptr必须是new出来的，不能是栈数组地址
求值 eval(double x) 用秦九韶算法时，指针访问顺序为什么必须从高次到低次？
秦九韶（Horner）方法本质是递推：((aₙ·x + aₙ₋₁)·x + aₙ₋₂)…，要求系数按降幂排列。但前面约定升幂存，所以循环必须倒着遍历指针——这是最常被忽略的逻辑反转点。若强行按升幂写正向循环，公式会变成错误的 (((a₀·x + a₁)·x + a₂)…，结果完全不对。
- 正确写法：
double res = coeffs[degree]; for (int i = degree-1; i >= 0; --i) res = res * x + coeffs[i]; - 如果系数指针不带阶数信息（比如只传
double* p），必须额外传入长度参数，否则无法确定degree - 对超大次数多项式，注意
double累计误差——这不是指针问题，但裸指针绕过了vector::at()的边界检查，越界读会静默出错
如何安全传递指针给外部 C 数值库（如 GNU Scientific Library）？
GSL 的多项式求根函数 gsl_poly_complex_solve() 要求系数数组首元素为最高次项，且长度为 n+1（n 次多项式）。而你内部按升幂管理，所以调用前必须临时复制并翻转顺序——不能复用原指针，否则破坏封装性。
立即学习“C++免费学习笔记（深入）”；
- 示例：
double* gsl_ready = new double[deg+1]; for (int i = 0; i - 务必用
gsl_free或手动delete[]清理该副本，GSL 不接管内存 - 若库函数声明为
const double*，仍需保证原始指针所指内存不被提前释放——析构函数里不能删，得等 GSL 调用完再删
裸指针本身不难，难的是所有边界条件都得自己兜底：内存谁分配谁释放、阶数和数组长度是否同步、内外部数据布局是否一致。一旦某个环节脱节，调试时往往只看到 NaN 或段错误，根本看不出是多项式对象早被析构了。
