std::linalg 在 C++26 中尚未存在，仍处于 TS 草案阶段，未被标准采纳，主流编译器均未实现；当前应使用 xtensor、armadillo 等第三方库，并通过抽象接口解耦以利未来迁移。
std::linalg 在 C++26 中还不存在
目前（截至 2024 年中），std::linalg **并未进入任何已发布的 C++ 标准**，C++23 是最新正式标准，C++26 尚未发布，且 std::linalg 仍处于 TS（Technical Specification）草案阶段，未被委员会完全批准，主流编译器（GCC、Clang、MSVC）均未实现它。
你看到的示例或文档，大概率来自：std::experimental::linalg（旧版实验性提案）、第三方库（如 xtensor、xtl、armadillo）的模拟接口，或博客/教程的超前假设。
- Clang 18 和 GCC 14 都不支持
#include <linalg></linalg>或std::linalg::matrix_multiply - 即使启用
-std=c++2b或-std=c++26（GCC/Clang 的预发布标志），也不会启用std::linalg - MSVC 在 /std:c++latest 下同样不提供该头文件或命名空间
现在能用的“最接近 std::linalg”的方案
如果你想要类似 std::linalg 的轻量、无依赖、基于 std::span 和迭代器的矩阵运算风格，目前唯一可行的是直接使用 std::experimental::linalg —— 但它已被弃用，且仅在极少数环境（如某些 libc++ 实验分支）中短暂存在过，**不推荐用于新项目**。
更实际的选择是转向成熟、标准化程度高、接口清晰的第三方库：
立即学习“C++免费学习笔记（深入）”；
-
xtensor：支持懒求值、广播、类 NumPy 语法，头文件仅依赖，xt::xarray<double></double>+xt::linalg::dot可替代大部分std::linalg设想场景 -
armadillo：底层调用 OpenBLAS/LAPACK，语法简洁，mat A, B; mat C = A * B;直观可靠 -
blaze：表达式模板优化激进，适合高性能密集计算，但编译时间长、错误信息难读
注意：xtensor 的 xt::linalg::solve 和 xt::linalg::svd 等函数名，容易让人误以为是标准库，其实它们属于 xt 命名空间，和 std::linalg 无任何实现或设计继承关系。
编译器报错 “fatal error: linalg: No such file or directory” 怎么办
这是最常遇到的卡点 —— 你写了 #include <linalg></linalg>，编译器直接报错。这不是配置问题，而是因为该头文件根本不存在于你的工具链中。
- 删掉
#include <linalg></linalg>，它不会被任何当前编译器识别 - 不要尝试用
-I指向某个自制头文件来“模拟”，这会导致 ADL 失败、SFINAE 错误、与未来标准不兼容 - 如果是在阅读论文或提案（如 P1385R7），请明确区分「提案描述」和「可用实现」——提案里写的
std::linalg::symmetric_matrix不等于你现在能 new 出来的类型
顺带一提：C++ 标准库至今没有原生多维数组类型，std::mdspan（C++23 引入）只是视图，不带运算；std::linalg 若将来落地，也只会提供算法（如 matrix_product），而非矩阵容器。
等 C++26 正式支持 std::linalg 之前，该怎么组织代码才不白写
核心原则：把矩阵运算逻辑和具体实现解耦，避免硬绑某套 API。
- 用自由函数封装运算，例如定义
my::matmul(A, B)，内部可切换xtensor/armadillo/ 自研 BLAS 调用 - 参数统一用
std::span<const double></const>+ 行列尺寸，而非xt::xarray或arma::mat—— 这样未来迁移到std::linalg时，只需重写函数体，调用侧几乎不动 - 避免在业务代码里直接写
A(0,1) = 3.14这类索引操作；改用my::set_element(A, row, col, val)，方便后续适配不同内存布局（比如std::linalg可能要求列优先视图）
真正容易被忽略的点是：即使 C++26 最终纳入 std::linalg，它也只定义算法语义（比如乘法精度、NaN 传播规则），不规定内存布局、分配方式或异常策略 —— 这些仍需你自己把控，别指望“标准库一上，所有矩阵代码自动变健壮”。
