std::submdspan 是零拷贝、类型安全、可组合的多维切片视图机制，非语法糖；它支持混合切片（如区间、全取、偶数索引），而 operator[] 仅支持单下标或完整坐标，无法表达此类需求。
std::submdspan 在 C++26 中不是简化多维切片的“语法糖”，而是提供了一种**零拷贝、类型安全、可组合的视图机制**，专为高性能数值计算设计。它不改变原数据布局，也不引入运行时开销，但要求你显式理解并指定每个维度的切片策略。
为什么不能直接用 operator[] 做多维切片？
原始 mdspan 支持 operator[]，但只支持单下标（返回降维后的视图）或完整坐标元组（返回标量）。无法表达“取第 1 维的 [2,5)，第 2 维的全部，第 3 维的偶数索引”这类混合切片——这正是 submdspan 的存在理由。
常见错误现象：
auto s = mds[std::pair{2,5}]; // 编译失败：mdspan 不支持 pair 切片你得到的是 SFINAE 失败或晦涩的模板推导错误，而非清晰语义。
submdspan 的三个核心参数怎么选？
调用形式为 submdspan(mdspan, args...)，其中每个 args 对应一维，类型决定行为：
立即学习“C++免费学习笔记（深入）”；
-
std::tuple<extents... stride...></extents...>→ 静态切片（编译期确定，最快） -
std::pair<ptrdiff_t ptrdiff_t></ptrdiff_t>→ 动态区间（如{2, 5}表示 [2,5)） -
std::integral_constant<size_t n></size_t>或字面量N→ 固定索引（该维退化为 0 维）
性能影响：使用 std::pair 会引入少量运行时计算（起始+长度），但现代编译器通常能内联优化；若所有维度都用字面量或 std::integral_constant，整个 submdspan 视图的 stride 和 offset 可全在编译期算出。
数值计算中容易踩的坑：stride 与 layout 陷阱
submdspan 返回的新 mdspan 保持原 layout（如 layout_left），但其 extents 和 stride 会根据切片重算。如果你手动计算偏移或传给底层 BLAS/LAPACK 接口，必须用 sub.view() 获取新视图的 data_handle() 和 mapping().stride(i)，不能复用原 mdspan 的 stride。
典型误用：
auto sub = std::submdspan(A, std::pair{1,4}, std::pair{0,3});
// 错！假设 sub.data() + 2*sub.extent(1) 是第 2 行起点
// 正确做法是：sub.data() + 2 * sub.mapping().stride(0)尤其在非连续 layout（如 layout_stride）下，手算偏移几乎必然出错。
和 mdspan 构造函数比，submdspan 真的更安全吗？
是的，但仅限于维度契约层面。它强制你为每一维提供明确切片意图，编译器会检查维度数量是否匹配、参数类型是否合法（比如不能对 0 维 extent 用 std::pair）。但它不验证逻辑合理性——例如对 shape [10,20] 传入 std::pair{15,25} 不报错，运行时访问越界仍由你负责（UB）。
兼容性注意：C++26 尚未正式发布，GCC 14/Clang 18 起提供实验性支持，需开启 -std=c++2b 并定义 __cpp_lib_mdspan >= 202306L；MSVC 尚未实现。生产环境慎用。
最易被忽略的一点：submdspan 返回的是一个新 mdspan 类型，其 element_type 和原视图完全一致，但 layout_type 和 accessor_type 可能因切片方式隐式变化（尤其是涉及 layout_stride 时），直接 static_cast 或模板特化匹配容易失败。
