GSL是补足标准库安全缺口的轻量工具集，提供gsl::at()越界检查、gsl::narrow()截断防护、gsl::not_null<>空指针编译期拦截，但需启用C++ Core Guidelines检查器才能发挥预警作用。
GSL 不是“替代”标准库，而是帮你更安全地用好标准库的轻量工具集——它不提供新容器或算法，只补足边界检查、空指针防护、类型转换等关键安全缺口。
什么时候该用 gsl::at() 而不是 operator[]
当你在循环里用非常量索引访问 std::vector、std::array 或原生数组时，operator[] 完全不检查越界，而编译器（尤其开启 MSVC 的 C++ Core Guidelines 检查）会直接报 C26446 警告。
- ✅ 安全写法：
gsl::at(vec, i)或vec.at(i)—— 两者都抛std::out_of_range，但gsl::at对原生数组也有效 - ❌ 危险写法：
vec[i]（i是变量）、arr[i]（arr是int arr[10]） - ⚠️ 注意：
std::string_view的operator[]同样不安全，也需改用gsl::at(sv, i)
#include <gsl/gsl>
#include <vector>
std::vector<int> v = {1, 2, 3};
int x = gsl::at(v, 5); // 运行时报 std::out_of_range，而非未定义行为如何避免 static_cast 引发的静默截断？用 gsl::narrow 和 gsl::narrow_cast
比如把 uint32_t 拆成三个 uint8_t 像素值时，static_cast 不报错，但高位非零会导致数据丢失——C26472 就是为此而设。
- ✅
gsl::narrow<uint8_t>(v >> 16)：严格检查，越界则抛gsl::narrowing_error - ✅
gsl::narrow_cast<uint8_t>(v & 0xFF)：明确承认可能丢数据，且你已确认安全 - ❌ 不要用
static_cast<uint8_t>(v)替代，尤其在处理外部输入或计算中间值时
auto rgb_from_24bit(uint32_t v) noexcept {
return std::array<uint8_t, 3>{
gsl::narrow<uint8_t>(v >> 16), // 安全：高位必须为 0
gsl::narrow_cast<uint8_t>((v >> 8) & 0xFF), // 显式接受低位截断
gsl::narrow_cast<uint8_t>(v & 0xFF)
};
}为什么 gsl::not_null 比 “加个注释说不能传 nullptr” 强得多
它把空指针检查从运行时提前到编译期，且对裸指针、智能指针、自定义句柄都统一支持。一旦传入 nullptr，连编译都过不去。
立即学习“C++免费学习笔记（深入）”；
- ✅ 函数参数强制非空：
void draw(gsl::not_null<Shape*> s)，调用draw(nullptr)直接报错 - ✅ 支持智能指针：
gsl::not_null<std::shared_ptr<T>>，避免make_shared<T>()返回空的误用 - ⚠️ 注意：
gsl::not_null是零开销抽象（无成员变量），但构造时若传入空指针，行为是未定义（所以务必靠编译器拦截）
void process(gsl::not_null<int*> p) {
*p = 42; // 编译器保证 p != nullptr，可放心解引用
}
int x = 0;
process(&x); // ✅ OK
// process(nullptr); // ❌ 编译失败真正容易被忽略的是：GSL 的安全机制只在你「主动启用」时才起作用——MSVC 需开启 C++ Core Guidelines 规则集，Clang/GCC 则依赖静态分析工具（如 clang-tidy 的 cppcoreguidelines-* 规则）。不配置检查器，gsl::at 和 gsl::narrow 依然能用，但警告不会自动出现，等于关掉了最重要的哨兵。
