结论：所谓“永远不会抛出异常的自定义异常安全容器”本身不成立，因容器异常行为取决于元素类型T和分配器的实际异常规范；标准容器无法单方面保证noexcept，只能通过契约式noexcept声明将责任明确归于T。
为什么“永远不会抛出异常的自定义异常安全容器”这个目标本身就有问题
直接说结论：std::vector、std::string 等标准容器在构造、赋值、push_back 等操作中，只要其元素类型 T 的构造/复制/移动可能抛异常，容器就可能抛异常——这是 C++ 标准明确允许且无法绕过的。所谓“永远不会抛出异常”，只能靠限制元素类型和使用方式来逼近，而非容器自身能单方面保证。
真正可落地的目标是：**让容器自身不引入额外异常路径，并为用户提供 noexcept 接口契约（当且仅当 T 满足相应 noexcept 要求时）**。
如何用 noexcept 限定接口并依赖 T 的异常规范
关键不是“屏蔽异常”，而是把异常责任清晰地交给元素类型。例如实现一个极简的 stack_array（栈上固定大小数组封装）：
noexcept
表达式都显式检查 T 的能力，而不是硬写 noexcept(true)——后者会在 T 实际抛异常时导致程序调用 std::terminate。
-
noexcept不是装饰，是契约：它必须与T的实际行为一致 - 不能对
std::vector<:string>声称“永不抛异常”，因为std::string的默认构造可能因内存分配失败而抛std::bad_alloc - 若你控制
T（如struct Vec3 { float x,y,z; };），则整个容器天然noexcept
哪些操作根本没法做到 noexcept，必须提前说明
动态内存分配相关操作，在 C++ 中无法规避异常风险（除非全程禁用堆、或使用自定义 nothrow 分配器并检查返回值）：
-
std::vector::reserve()和resize()：底层operator new可能抛std::bad_alloc，即使你写了noexcept，标准库也不会帮你吞掉它 -
std::map::insert()：节点构造 + 内存分配双重风险 - 任何接受可变参数模板或泛型
Allocator的容器，其异常安全性最终取决于传入的T和Allocator
所以，如果你看到某个“异常安全容器”文档里没提它依赖的 T 和 Allocator 的 noexcept 要求，那它大概率是在模糊责任边界。
替代方案：用 std::array 或静态缓冲 + std::span 规避堆分配
真要追求确定性无异常，最可靠的方式是彻底避开运行时内存分配：
-
std::array：所有操作默认noexcept（只要int是平凡类型） - 用
std::aligned_storage_t+ placement-new 手动管理对象生命周期（需自行保证析构和异常安全顺序） - 用
std::span封装外部生命周期已知的内存块，零开销且必然noexcept
这些不是“容器的升级版”，而是设计取舍：放弃动态大小，换来可证明的异常自由。工程中该选哪个，取决于你是否真的需要运行时可变容量。
最容易被忽略的一点是：异常安全 ≠ 不抛异常；它指资源不泄漏、对象状态不损坏。哪怕某函数声明了 noexcept，若内部 assert 失败或调用了未定义行为，程序一样会终止——这不属于异常范畴，但后果同样严重。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
