简介：Eigen3.zip 提供一套基于2019年12月最新版Eigen3源码编译的 C++ 模板矩阵库，面向使用 VS2017 与 CMake3 的 Windows 开发者，也适合有 MATLAB 基础、需要转向 C++ 数值计算的人群，在视觉、机器人、仿真等领域应用广泛。编译配置已经打通，除 include 目录中的头文件外，还提供配套的 CMake 导入配置与库文件，使用者无需从源码自行构建，可直接在 VS 工程中完成引用和链接，快速获得稠密/稀疏矩阵运算、几何变换、特征值分解、线性方程组求解等能力，覆盖从基础向量操作到高阶稀疏求解与张量计算的常见需求，支持模板化的自定义标量类型，便于算法移植。资源共 482 个文件，主体为 424 个 h 头文件，另有 4 个 cmake 配置及一批模块支持文件，模块划分清晰，涉及 dense、sparse、geometry、eigenvalues、LU、QR、SVD、Cholesky 等常用子模块，整体压缩包约 1.45MB，小巧便于分发与版本管理。目前已有 300 余人浏览学习，适合需要将 Eigen3 集成到 VS 项目的初学者，以及希望快速搭建矩阵计算原型的工程技术人员参考使用。
1. 先聊聊 Eigen3.zip：它解决什么问题、适合哪些人
第一次从同事手里拿到 Eigen3.zip 时，我还以为里面是个安装包，解压完发现全是头文件，复制到 include 路径后直接编译，报错刷了整整一屏。后来才明白，Eigen3 就是这样的一个库：不需要安装、不需要编译成动态库，解压后把目录放对位置就能用。它解决的是 C++ 里最日常的数值问题——向量运算、矩阵乘法、解线性方程组、特征分解、奇异值分解，而这些恰恰是机器人运动学、三维几何、SLAM 后端、仿真前处理里绕不开的计算基座。
适合用它的开发者有两类：一类是写算法模块的人，希望代码不背着一大堆运行时依赖到处跑；另一类是已经被 OpenCV 的 Mat 绕晕的人，想找一个更纯粹、类型更明确的矩阵库。Eigen3 还常被视为“可嵌入”的库，因为它的模板机制让编译器在编译期就确定矩阵尺寸和元素类型，该展开的循环展开，该内联的内联。这篇文章会从解压一个 zip 包讲起，一路聊到目录结构、CMake 集成、常用求解器、性能参数，以及那些让不少人翻过车的对齐和模板报错问题。整体节奏偏实战，新手照着能跑通，熟手也能对得上自己踩过的坑。
2. 为什么选 Eigen3 而不是其它矩阵库：模板机制与三次选型对比
2.1 纯头文件模板库的核心机制：编译期定类型、定尺寸
Eigen3 和一般“编译好再链接”的库不是一回事。你在代码里写Eigen::Matrix<double, 3, 3> A;时，double、3、3会作为模板参数参与实例化，编译器会专门生成一套针对“3×3 double 矩阵”的运算代码。这意味着矩阵的尺寸信息在编译期就是可见的，编译器能做大量的循环展开和常量折叠。运行时不再依赖任何共享库，只要头文件路径对，就能在目标机器上直接编译。这也是为什么很多人愿意把 Eigen3.zip 放进工程代码库一起管理，而不是依赖系统上安装某个版本。
更关键的是表达式模板机制。写A + B * C时，Eigen 不会立刻把中间结果算出来，而是构造一个表达式对象，直到这个表达式被赋值给一个具体类型的矩阵变量时才做实际求值。这样可以在一条语句里把多次运算合并在一起，避免产生临时矩阵，也减少了遍历内存的次数。理解这一点，是后面排查“auto 接表达式结果后数值变乱”等问题的前提。你看到的很多 Eigen 报错，其实都源于模板实例化过程中的类型不匹配，而不是算法算错了。
2.2 和三种常见替代方案的对比：选型结论
我先说结论，再解释依据。如果你是做 C++ 里的数值计算、几何计算、状态估计这类纯算法工作，Eigen3 是默认首选；如果你的主要任务是图像处理和视频管线，OpenCV 的 Mat 可能更顺手；如果你在写偏科学计算、统计类的代码，Armadillo 的上手体验更好，但它往往需要额外接 LAPACK/BLAS。
| 方案 | 形态 | 额外依赖 | 适合场景 | 常见槽点 |
|---|---|---|---|---|
| Eigen3 | 纯头文件模板库 | 无，可选 BLAS/MKL | 算法组件、嵌入式、几何计算 | 模板报错难读、编译时间偏长 |
| OpenCV | 二进制库 | 大量运行时动态库 | 图像视频处理，顺手做矩阵 | 库体大、矩阵类型与图像耦合 |
| Armadillo | 源码库 | 建议 LAPACK/BLAS | 科学计算、统计 | 封装较厚，底层问题难以定位 |
OpenCV 的 Mat 强在图像相关的内存布局和视觉算子，但它的矩阵运算接口远没有 Eigen 细。如果你只想算旋转矩阵、四元数、雅可比矩阵，为这个去依赖整个 OpenCV 是得不偿失的。Armadillo 的语法比 Eigen 更接近 MATLAB，但它把很多计算下放到 BLAS/LAPACK，一旦遇到环境里没有这套库的情况，性能就会掉得很厉害，排查起来也麻烦。Eigen3 的优势在于“不需要任何外部库也能跑得很好”，需要更强性能时再通过编译宏接 MKL——这是一个从易到难渐进的过程。
还有一类“自己写 Matrix 类”的方案，我也见过不少。矩阵尺寸固定、只有加减乘法，自己写确实可控；可一旦需求扩展到求逆、特征值、稀疏矩阵，自己写的版本就会陷入无底洞。Eigen 把这些高频矩阵操作都做成了现成的类，且按需包含头文件，不会让没用到的代码塞进二进制。选型的真正逻辑是：看你的瓶颈是算法开发速度还是运行时依赖。
2.3 什么时候不该用 Eigen3
不是所有场景都适合上 Eigen3。如果整个工程已经被 OpenCV 的 Mat 贯穿，只为一段矩阵运算引入另一套矩阵类型，那两头转换的成本会抵消收益。如果团队维护的是纯 C 工具链，或者需要对外提供稳定的 C ABI，模板库也会让接口变得很难看。还有一种情况是大规模 GPU 矩阵计算，Eigen 虽然能通过后端调用底层库，但它本身的定位是通用 CPU 数值库，这时候应该直接用专门的 GPU 计算框架。换句话说，Eigen3 最适合的场景是：我要在 C++ 里做数值计算，但我不想背着一个重型的运行时依赖。
3. 拿到 Eigen3.zip 之后：解压、目录结构、CMake 集成与第一个程序
3.1 解压后的目录结构：先看三样东西
拿到 Eigen3.zip，先别急着复制到 include 目录。我一般会在临时目录解压，看清楚结构再决定怎么放：
unzip Eigen3.zip -d eigen3_tmp cd eigen3_tmp ls -F常见的压缩包解压后，核心内容是这样几部分：Eigen/目录存放真正的核心头文件，日常写#include <Eigen/Dense>找的就是它；unsupported/目录放的是非标准模块，像一些实验性的傅里叶变换、多项式功能；还会有signature_of_eigen3_matrix_library之类的标记文件，以及某些版本自带的 CMake 配置文件。真正干活的是Eigen/目录，这一点要记牢。
放 include 路径时，你只需要指向“包含Eigen目录的那一层”。比如把解压后的内容放进工程的third_party/eigen3，那么代码里写#include <Eigen/Dense>，编译器会从third_party/eigen3/Eigen/Dense找到这个头文件。最容易翻车的操作是：解压后又把目录多包了一层，代码写#include <eigen3/Eigen/Dense>，而 CMake 指定的路径却是外层的上一级，结果找不到头文件。Eigen3.zip 文件名里带了 Eigen3，但集成时不要跟着压缩包名字多套一层目录，这是一个非常典型的集成问题。
3.2 用 CMake 把 Eigen3 接进工程：两种可靠方式
新工程推荐用find_package的方式，前提是你的 zip 包或系统环境里提供了 CMake 配置。在 CMakeLists.txt 里这样写：
cmake_minimum_required(VERSION 3.16) project(FirstEigen CXX) set(CMAKE_CXX_STANDARD 17) find_package(Eigen3 REQUIRED NO_MODULE) add_executable(demo main.cpp) target_link_libraries(demo Eigen3::Eigen)逻辑说明：NO_MODULE是要求以 Config 模式查找，也就是去找Eigen3Config.cmake这类配置文件。找到后，Eigen3::Eigen这个导入目标会自带 include 目录，你不需要再手动include_directories。这种方式的好处是版本和头文件路径由 CMake 统一接管，适合团队里多个工程复用同一套依赖。
如果你的 zip 包没有带 CMake 配置文件，或者你希望工程在拿到 zip 后“零查找”直接编译，那就用更简单的 include 方式：
cmake_minimum_required(VERSION 3.16) project(FirstEigen CXX) set(CMAKE_CXX_STANDARD 17) add_executable(demo main.cpp) target_include_directories(demo PRIVATE ${CMAKE_SOURCE_DIR}/third_party/eigen3)逻辑说明：这里直接告诉编译器去third_party/eigen3找头文件，Eigen 本来就是纯头文件，目录放对就能编。用target_include_directories而不是全局的include_directories，是为了避免头文件路径污染其它 target。注意代码里应该写#include <Eigen/Dense>，因为编译器会在你指定的目录下找Eigen/Dense。如果你把路径写成了third_party/eigen3/Eigen，代码又写<Eigen/Dense>，那实际查找路径就变成了third_party/eigen3/Eigen/Eigen/Dense，这就是最常见的“明明解压对了却编不过”的原因。
3.3 第一个可以运行的程序：从定义到求解
集成跑通后，第一个程序建议就做一件事：定义一个矩阵，解一个线性方程组，看看残差。这样能同时验证头文件路径、编译环境和求解逻辑：
#include <iostream> #include <Eigen/Dense> int main() { Eigen::Matrix3d A; A << 1, 2, 3, 4, 5, 6, 7, 8, 10; Eigen::Vector3d b(1, 2, 3); Eigen::Vector3d x = A.colPivHouseholderQr().solve(b); std::cout << "x = " << x.transpose() << std::endl; std::cout << "residual = " << (A * x - b).norm() << std::endl; return 0; }编译并运行：
g++ -std=c++17 main.cpp -o demo ./demo逻辑说明：Matrix3d是Eigen::Matrix<double, 3, 3>的别名，d代表 double 类型；<<操作符按行填充矩阵，顺序和按列填充的习惯不同，读者可以试试把最后一行换成7, 8, 9，矩阵变成奇异后，QR 求解器仍然会返回一个解，但残差可能不再接近零，这个现象后面避坑章节会解释。solve返回解向量，(A * x - b).norm()计算残差的二范数，残差越小说明求解结果越可靠。
这个程序跑通之后，你实际上已经完成了三个关键验证：目录结构放对了、CMake 引用正确、编译器能实例化 Eigen 模板。我一般会先输出残差看量级，而不是盯着解向量的数值看。如果残差在 1e-14 这个量级，说明编译和求解链路都是通的。
4. 常用操作与关键参数：从矩阵定义到解线性方程组
4.1 固定尺寸与动态尺寸：把类型当作参数
Eigen3 里“参数”很大程度是写在类型上的。固定尺寸的矩阵在编译期就把行列数定死，动态尺寸则在运行时通过resize决定。两者的选择直接影响内存分配和性能表现：
| 特性 | 固定尺寸 | 动态尺寸 |
|---|---|---|
| 分配位置 | 栈 | 堆 |
| 尺寸可变 | 否 | 是 |
| 小矩阵性能 | 循环展开、零 malloc | 有堆分配开销 |
| 适用场景 | 旋转矩阵、小状态量 | 数据驱动的大矩阵 |
固定尺寸用起来是这样的：
Eigen::Matrix<double, 3, 3> fixedA; // 编译期确定 3x3 Eigen::MatrixXd dynamicB; // 动态尺寸 dynamicB.resize(600, 400); // 运行时确定 600x400逻辑说明：MatrixXd是Matrix<double, Dynamic, Dynamic>的别名，Dynamic表示维度在运行时确定。固定尺寸类型内部直接用栈数组保存数据，没有堆分配；动态尺寸内部管理一块堆内存，resize会重新分配。这就是为什么在性能敏感代码里反复创建小矩阵时，动态尺寸可能成为无感知的黑洞——每一次构造都可能伴随一次内存分配。
我的选择标准是：矩阵维度在编译期能确定、且总元素数不超过几十个，就优先用固定尺寸。比如 3×3 旋转矩阵、6×6 信息矩阵、四元数对应的 4 维向量，这些都是固定尺寸的典型场景。维度大到几百上千，或者运行时由数据决定，才用动态尺寸。别把所有矩阵都写成MatrixXd，那样在小矩阵场景里等于主动放弃了栈分配和循环展开的优化空间。
4.2 解线性方程组：QR、LU、LLT 各管什么场景
解Ax = b是日常最高频的线性代数操作，但选错求解器会导致结果不稳定或速度差很多。Eigen 提供了多种分解方式，核心的几种对比是这样的：
| 求解器 | 矩阵要求 | 典型场景 | 数值稳定性 |
|---|---|---|---|
| LLT | 对称正定 | 正规方程、Hessian 矩阵 | 对病态敏感 |
| LDLT | 对称，可半正定 | 带约束的 Hessian | 较稳 |
| ColPivHouseholderQR | 任意方阵 / 最小二乘 | 通用首选 | 稳 |
| FullPivLU | 任意方阵 | 接近奇异 | 最稳但慢 |
| BDCSVD | 任意，可矩形 | 秩亏最小二乘 | 数值上最稳 |
通用场景下，我一般默认ColPivHouseholderQR，它不要求矩阵对称，对付病态矩阵也比无主元分解更稳。如果你明确知道矩阵是对称正定的，比如很多优化问题里的 Hessian，可以用 LLT 或 LDLT，它们比 QR 快很多。下面这段代码演示了如何复用求解器对象：
#include <Eigen/Dense> #include <iostream> Eigen::VectorXd solveLeastSquares(const Eigen::MatrixXd& A, const Eigen::VectorXd& b) { Eigen::ColPivHouseholderQR<Eigen::MatrixXd> qr(A); Eigen::VectorXd x = qr.solve(b); if (qr.info() != Eigen::Success) { std::cerr << "rank deficient or numerical failure" << std::endl; } return x; }逻辑说明：把求解器对象显式构造出来，可以在多次solve(b)时复用矩阵分解的结果，避免每次都重新做一遍 QR 分解。qr.info()返回Eigen::Success才表示求解过程被判定为成功，否则说明矩阵可能秩亏或数值异常。这里ColPivHouseholderQR<Eigen::MatrixXd>的模板参数就是矩阵类型，如果 A 是固定尺寸的 6×6 矩阵，这里也可以写成ColPivHouseholderQR<Eigen::Matrix<double, 6, 6>>。
当你发现 QR 解出的残差很大，或者解向量的值数量级异常，第一步不是换求解器，而是检查矩阵的条件数。常见做法是用 SVD 求最大和最小奇异值，比值就是条件数的估计。Eigen 里JacobiSVD可以直接算奇异值，这个检查步骤能帮你判断问题是出在矩阵本身病态，还是出在选型上。
4.3 性能相关参数：优化开关、对齐与 MKL
Eigen3 的性能表现，很大程度由编译选项和预定义宏决定。最简单的加速组合是-O2 -DNDEBUG，NDEBUG会关闭 Eigen 内部的边界检查和断言，运行速度提升明显，但代价是出错时不提示。我的习惯是调试阶段不开NDEBUG，跑通验证后再在 Release 构建里开启。
如果你想进一步压榨大矩阵乘法的性能，可以在包含任何 Eigen 头文件之前定义宏，让 Eigen 把部分运算下放给 BLAS 或 MKL：
// 必须在 include <Eigen/Dense> 之前定义 #define EIGEN_USE_BLAS #define EIGEN_USE_MKL #define EIGEN_MAX_ALIGN_BYTES 32 #include <Eigen/Dense>逻辑说明：EIGEN_USE_MKL会让 Eigen 在矩阵乘法等耗时操作上调用 MKL 的 dgemm 之类接口；EIGEN_USE_BLAS是更通用的 BLAS 调用接口，实际使用中二选一即可，两个同时开可能造成符号冲突。EIGEN_MAX_ALIGN_BYTES控制最大对齐字节数，默认值会根据编译目标自动选择，常见是 16 或 32；如果你的目标平台不支持这么高的对齐要求，可以调成 0，强制走未对齐路径，保守但稳定。
编译时还需要链接对应的库，以 MKL 为例：
g++ -std=c++17 -O2 -DNDEBUG -march=native main.cpp -o demo \ -lmkl_intel_lp64 -lmkl_sequential -lmkl_core参数说明：-march=native让编译器根据当前 CPU 的特性启用对应的 SIMD 指令集；-lmkl_*链接 MKL 运行时。实际经验是，小矩阵没必要开 MKL，因为外部调用有函数开销，200 阶以下的矩阵直接走 Eigen 自带内核并不会慢多少；矩阵边长到几百甚至上千时，MKL 的加速效果才明显。这块属于“到了性能瓶颈再优化”的方向，不要一上来就上。
5. Eigen3 常见踩坑与排查：对齐、模板报错、悬空引用、编译慢
5.1 结构体里嵌 Eigen 矩阵导致编译失败或运行崩溃：对齐问题
现象：定义一个结构体，成员里有Eigen::Vector4d q和Eigen::Vector3d t，编译时没问题，一旦用new Pose()创建对象，或者把对象放进std::vector<Pose>并触发扩容，程序可能在运行时断言崩溃。某些编译器还会直接报错，比如成员按值传参时拒绝编译。原因：Vector4d、Matrix3d这类固定尺寸的小矩阵有 16 字节甚至更高的对齐要求，而默认operator new和std::vector的分配器并不保证为每个对象都分配在对齐地址上。
解决：在结构体里声明对齐所需的 operator new，同时给 vector 指定专用的对齐分配器：
struct Pose { Eigen::Vector4d q; Eigen::Vector3d t; EIGEN_MAKE_ALIGNED_OPERATOR_NEW }; std::vector<Pose, Eigen::aligned_allocator<Pose>> poses;逻辑说明：EIGEN_MAKE_ALIGNED_OPERATOR_NEW这个宏会重载operator new，确保new Pose()分配的内存满足 Eigen 的对齐要求；Eigen::aligned_allocator<Pose>则用于标准容器。C++17 的内存对齐保证比老标准强很多，很多场景下这个宏可以省略，但为了兼容老编译器和不同平台，写上是最稳妥的“后悔药”。这条是我第一次面对 Eigen 和结构体组合时踩得最深的坑，遇到不明所以的运行时崩溃，先检查结构体里有没有固定尺寸的 Eigen 成员。
5.2 模板报错刷屏：从最后一行开始读
现象：只是把两个尺寸不匹配的矩阵相加，编译器却吐出上百行错误，信息里全是Eigen::internal::...这种内部模板类型，人眼根本找不出问题在哪。原因：Eigen 使用表达式模板，真正的错误往往发生在模板实例化层级的最深处，前面的上百行只是实例化路径的展开过程。
解决：直接从最后一个error:开始读，几乎总有一句人类能看懂的话，比如INVALID_MATRIX_PRODUCT、YOU_MIXED_MATRICES_OF_DIFFERENT_SIZES、static_assert failed。如果错误发生在很长的表达式里，就把表达式拆成中间变量，缩小定位范围：
Eigen::MatrixXd r = A * B + C; // 改成 Eigen::MatrixXd t = A * B; Eigen::MatrixXd r = t + C;逻辑说明：拆开之后，编译器能把错误精确定位到某一个赋值行，而不是一串嵌套表达式。另一个减少阅读成本的做法是给类型起短别名：
using Vec3 = Eigen::Vector3d; using Mat3 = Eigen::Matrix3d;报错信息里的类型名长度会大幅缩短，定位速度提升不少。血泪经验是：遇到static_assert failed不要从头开始读，直接看最后几行，再往回找对应的代码行。
5.3 auto 接收表达式结果：惰性求值带来的悬空引用
现象：某开发者写auto y = A * x;，下一行打印y，发现数值不对，甚至程序崩溃。尤其在函数里写auto result = compute();然后返回时，几乎必炸。原因：A * x返回的不是一个矩阵，而是一个表达式对象，它内部持有矩阵数据的引用。auto把这个表达式对象当普通值保存下来，如果A或x是临时对象，或者表达式对象跨越了原本的作用域，求值发生时就可能引用了已经析构的数据。
解决：接收计算结果时直接给出具体类型，或者调用eval()强制求值：
Eigen::VectorXd y = A * x; // 立即求值，安全 auto z = (A * x).eval(); // 显式求值，z 是真正的矩阵逻辑说明：第一种写法把表达式赋值给VectorXd，赋值过程会触发实际计算，变量持有计算后的数据，不再引用临时对象。第二种写法用eval()立刻生成真正的矩阵对象，z的类型就是Eigen::MatrixXd，不会悬空。团队代码评审时，我一般会要求：接收 Eigen 表达式一律写显式类型，不用auto。这条规则简单，但能避免大量深夜排查。
5.4 编译时间过长与增量编译失效：按需包含
现象：工程里有一个公共头文件common.h，里面写了一句#include <Eigen/Dense>，之后每次改动任意一个和 Eigen 相关的文件，整个工程几百个 cpp 全部重新编译。原因：Eigen/Dense会一次性拉进大量矩阵、求解器、几何算法的头文件，每个 cpp 都要实例化一遍模板，编译时间被急剧拉长。
解决：按需包含。只做基础乘法，就不要包含整个 Dense；要解线性方程组，再单独加对应求解器头文件。一份常用的最小包含清单：
| 包含的头文件 | 能用的功能 |
|---|---|
<Eigen/Core> | 矩阵向量定义与基础运算 |
<Eigen/Geometry> | 旋转、四元数、仿射变换 |
<Eigen/QR> | 列主元 QR 分解 |
<Eigen/SVD> | SVD 与奇异值计算 |
<Eigen/Sparse> | 稀疏矩阵相关 |
另一个更彻底的手段是隔离：公共头文件里不出现 Eigen 类型，用 PIMPL 或前置声明挡住，只在.cpp文件里包含 Eigen 头文件。这样改 Eigen 相关实现时，影响范围被限制在少数编译单元内。最后检查一遍工程里有没有“用不到却包含着的求解器头文件”，这是编译时间黑洞里最容易被忽视的一项。
6. 进阶技巧：用 Block 分块乘法绕开性能瓶颈，顺便验证一次求解精度
当矩阵乘法到了几百阶，又不想引入 MKL 也不想碰多线程时，一个经典做法是手动分块，把大矩阵切成固定大小的块，让参与运算的数据尽量留在缓存里。Eigen 的.block()接口做这件事非常方便：
const int N = 1024; const int BLK = 64; Eigen::MatrixXd A = Eigen::MatrixXd::Random(N, N); Eigen::MatrixXd B = Eigen::MatrixXd::Random(N, N); Eigen::MatrixXd C = Eigen::MatrixXd::Zero(N, N); for (int i = 0; i < N; i += BLK) { for (int j = 0; j < N; j += BLK) { for (int k = 0; k < N; k += BLK) { C.block(i, j, BLK, BLK) += A.block(i, k, BLK, BLK) * B.block(k, j, BLK, BLK); } } }逻辑说明：.block(行, 列, 行数, 列数)返回一个块表达式，内外三层循环对应分块乘法的累加方向。最里面的k循环是缓存局部性的关键，遍历顺序决定数据是反复被加载还是能留在 cache 里。BLK通常取 32 到 128，我在多数台式 CPU 上测下来 64 是个不错的起点。很多实现最后一步是确认分块没有改变数学结果：
double diff = (C - A * B).norm() / (A.norm() * B.norm()); std::cout << "relative diff = " << diff << std::endl;逻辑说明：直接用A * B求一次完整乘法作为参考，和分块结果对比。相对误差在 1e-14 量级说明分块逻辑正确，差异只是数值浮点舍入层面的，不是算法错误。这里也顺带验证了 Eigen 的求解链路没有出现意料之外的临时对象问题。养成一个习惯：我接手别人留下的 C++ 数值工程，第一件事是打开公共头文件看三样东西——它包含的是什么 Eigen 头文件、求解方程组用的哪种分解、有没有用auto接收表达式结果；这三个点查完，基本能判断作者有没有踩过常见的坑。希望这篇笔记帮到你。
本文还有配套的精品资源，点击获取
