not_null 不能直接用于裸指针赋值，因其隐式转换不校验空值，仅显式构造（如 gsl::not_null{p}）可能触发断言，且不监控后续指针变化；它仅强化接口契约，依赖静态分析工具生效。
为什么 not_null 不能直接用在裸指针上
not_null 是 GSL（Guidelines Support Library）中用于表达“该指针绝不能为 nullptr”意图的包装类型，但它**不接管所有权**，也不做运行时检查。常见错误是试图这样写：
int* p = nullptr;<br>gsl::not_null<int*> nn = p; // 编译通过，但行为未定义问题在于：默认构造和隐式转换不校验空值，只有显式调用
gsl::not_null::operator= 或构造函数传入空指针时，部分实现（如 Microsoft GSL）才触发断言——但这不是标准保证。
- 必须显式构造：
gsl::not_null<int> nn{p}</int>才可能触发断言（取决于 GSL 实现和编译宏，如GSL_THROW_ON_CONTRACT_VIOLATION） - 裸指针赋值给
not_null变量是隐式转换，多数 GSL 版本默认不拦截 - 若底层指针后续被置为
nullptr，not_null对象完全无法感知——它只管“构造/赋值那一刻”
owner 不是智能指针，只是语义标记
owner<t></t> 的唯一作用是向静态分析工具（如 C++ Core Guidelines Checker、Clang-Tidy）和人传递“这个指针拥有其所指对象的生命周期控制权”。它**不管理内存、不自动释放、不重载 delete**。写成这样毫无意义：
int* raw = new int(42);<br>gsl::owner<int*> owned = raw; // OK，但 delete owned; 是错的因为
owner 没有 operator delete，也不能直接传给 delete。
- 正确做法是：用
std::unique_ptr或std::shared_ptr管理资源，再用owner标记其原始指针（如函数参数）：void process(gsl::owner<int> p)</int> -
owner常见于函数签名，表示“调用者应确保传入的是有效所有者”，而非用于存储 - 误以为
owner能防止 double-delete 或泄漏，是典型误解——它不改变任何运行时行为
与 std::span 配合使用时，not_null 的真正价值在哪
当函数接受缓冲区时，std::span 本身已隐含非空（长度为 0 时仍合法），但若业务逻辑要求“至少一个元素”，仅靠 span 不够。此时 not_null 可强化契约：
void handle_first_element(gsl::not_null<std::span<int>> s) {<br> // s.data() 必不为空，且 s.size() > 0<br> do_something(s[0]);<br>}注意：这里 not_null 包裹的是 std::span，不是原始指针——它阻止了传入默认构造的空 span（即 std::span<int>{}</int>），而普通 span 默认构造是合法的且 data()==nullptr。
-
not_null<:span>></:span>在构造时检查span.data() != nullptr，比手动写assert(s.data())更统一 - 不要对
span内部指针再套not_null，比如not_null<decltype></decltype>—— 这既冗余又破坏span的完整性 - 若函数只读取首元素，用
not_null<span></span>比用裸指针 + 长度参数更安全、意图更清晰
GSL 安全性增强的关键前提：编译期约束 + 工具链配合
GSL 的 not_null 和 owner 不是银弹。它们的安全性依赖两个外部条件：一是启用编译器警告和静态分析（如 /analyze on MSVC, -Wnull-dereference in Clang），二是项目中统一约定并执行规则。例如：gsl::not_null 在 Release 模式下通常不带运行时检查，除非你定义了 GSL_UNENFORCED_ON_CONTRACT_VIOLATION=0 并链接调试版 GSL。
立即学习“C++免费学习笔记（深入）”；
- 不用静态分析工具时，
not_null几乎只起文档作用；用 Clang-Tidy 的cppcoreguidelines-pro-bounds-pointer-arithmetic规则才能捕获潜在空解引用 -
owner在 MSVC 的 Code Analysis 中能标记出“将owner传递给非owner参数”的违例，但 GCC 不支持 - 混合使用裸指针、
unique_ptr和owner时，最容易忽略的是：把unique_ptr::get()返回的指针存为owner，却忘了该指针失效后owner仍存在——这没解决悬垂问题
GSL 的安全性不在代码行里，而在团队是否真正在意每个指针的空状态和所有权归属。一旦放松对构造入口的校验，或跳过静态检查环节，not_null 和 owner 就只剩注释价值。
