你的这个模板化at()的想法真的很赞——编译期直接拦截越界，还能省掉运行时检查的开销，完美兼顾安全和性能。不过标准库没采用这种实现，主要有这么几个核心原因：

1. 接口一致性与向后兼容优先 #

标准库的容器接口设计一直非常看重一致性：不管是动态容器std::vector、std::deque，还是静态的std::array，它们的at()成员函数都是接受运行时参数的非模板函数。如果单独给std::array加一个模板化的at()重载，会打破这种统一的接口约定，让开发者在切换不同容器时需要额外适配，徒增学习和维护成本。

另外，C++标准的演进对向后兼容看得极重。如果给std::array::at()新增模板重载，哪怕功能再强，也可能和现有代码产生意外冲突——比如有些开发者可能已经自己实现了同名的模板扩展，或者代码里依赖了at()原本的运行时异常行为。

2. 场景覆盖的权衡：兼顾编译期和运行时 #

模板化的at()只能处理编译期已知的固定索引，但std::array的设计目标是同时支持编译期操作和运行时动态索引场景。标准库的at()必须覆盖这两种情况：当索引是运行时变量时，只能通过运行时检查抛出std::out_of_range异常，这是无法用模板实现的。

其实如果你只需要编译期安全的索引访问，标准库已经有现成的替代方案：std::get<std::array>()。它本身就是模板函数，编译期会直接检查索引是否越界，用法是std::get<10>(a)，和你写的a.at<10>()效果几乎一致，只是语法略有不同。

3. 标准委员会的折中设计 #

C++标准的制定是多方需求博弈的结果，需要平衡性能、易用性和学习曲线。模板化at()虽然好用，但并不是刚需——毕竟std::get已经提供了编译期安全访问的能力，再给at()加模板重载反而会让接口变得冗余复杂。

而且从C++20开始，std::array::at()已经支持constexpr了：当索引是编译期常量时，它会在编译期就检查越界并报错（通过constexpr断言，而非static_assert）。比如：

constexpr std::array<int, 5> a{1,2,3,4,5};
constexpr auto val = a.at(10); // C++20及以后编译期直接报错

这种设计既保留了原有接口的一致性，又实现了编译期安全，算是一个很务实的折中方案。

4. 留给开发者的自定义空间 #

标准库的定位是提供通用基础组件，不可能覆盖所有小众场景。如果你需要同时支持编译期模板索引和运行时动态索引的at()，完全可以像你计划的那样自定义array类——这正是C++的优势：允许开发者根据自身需求，在标准库基础上封装出更贴合业务的工具。

总的来说，你的思路非常有前瞻性，完全可以应用在自己的自定义容器里。标准库没这么做，更多是出于接口一致性、兼容性和场景平衡的考量而已。

内容的提问来源于stack exchange，提问作者Carlos Brito