推荐用默认构造（如std::shared_ptr ptr;）初始化空指针，避免传nullptr导致控制块异常；unique_ptr转移后裸指针立即失效；weak_ptr.lock()必须判空；自定义deleter会增大shared_ptr体积。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜
std::shared_ptr 初始化空指针时别直接传 nullptr
传 nullptr 给 std::shared_ptr 构造函数看似合理，但容易触发未定义行为或绕过资源管理逻辑。比如 std::shared_ptr<int>(nullptr)</int> 会构造一个空智能指针，但它不持有任何控制块——后续调用 use_count() 返回 0，reset() 行为也和预期不同。
更安全的做法是用默认构造或 std::shared_ptr<t>()</t> 显式构造空指针：
-
std::shared_ptr<int> ptr;</int>—— 推荐，语义清晰，控制块不存在，开销最小 -
std::shared_ptr<int> ptr = nullptr;</int>—— 编译通过，但底层仍调用shared_ptr(nullptr, Deleter{})，多一次空控制块分配（部分实现） - 避免
std::shared_ptr<int>(nullptr)</int>在条件分支里反复构造，可能泄漏控制块内存（某些 libstdc++ 旧版本有此问题）
std::unique_ptr 转移后访问 raw pointer 是常见崩溃源头
一旦 std::unique_ptr 调用 release() 或被移动（std::move(ptr)），它内部的裸指针就置为 nullptr，但原来指向的内存并未立即释放。此时若还保留了该裸指针副本（比如存到某个 int* 变量里），后续解引用就是野指针。
典型错误场景：
立即学习“C++免费学习笔记（深入）”；
- 从
std::unique_ptr<foo> p = std::make_unique<foo>();</foo></foo>拿出Foo* raw = p.get();，然后执行p.reset();或return std::move(p);—— 此时raw已失效 - 把
p.release()返回的指针交给 C API 后，忘了自己不再负责释放，又在别处 delete 它 - 调试时打印
p.get()地址，误以为“地址还在”就代表对象还活着
std::weak_ptr.lock() 返回空要立刻检查，不能假设一定成功
std::weak_ptr 的存在意义就是应对生命周期不确定的观察场景，lock() 失败不是异常，而是常态。很多同学写成 auto ptr = wp.lock(); ptr->do_something();，一旦 wp 所观察的 shared_ptr 已销毁，ptr 就是空，解引用直接 crash。
正确姿势是每次使用前做空检查：
- 用
if (auto ptr = wp.lock()) { ptr->do_something(); }—— C++17 后推荐，作用域自动限制 - 不要缓存
wp.lock()结果跨函数调用，哪怕只隔一行：auto ptr = wp.lock(); some_func(); ptr->xxx;中间some_func()可能触发销毁 -
wp.expired()只比lock()少一次引用计数增减，性能差异可忽略，但不能替代lock()后的空判断
自定义 deleter 导致 sizeof(std::shared_ptr) 翻倍很常见
默认 std::shared_ptr<t></t> 的大小通常是两个指针（8 字节 ×2 = 16 字节，x64）。但只要用了非默认 deleter（比如 lambda、函数对象、std::function），控制块就必须存储该 deleter 实例，导致 shared_ptr 对象本身变大——常见涨到 32 字节甚至更多。
影响不只是内存占用：
- 作为结构体成员时，padding 和 cache line 对齐可能恶化
- 频繁拷贝（如容器中传递）成本上升，尤其在 hot path 上
- lambda 捕获变量会让 deleter 不再是 trivially copyable，某些优化（如 memcpy 替代拷贝构造）失效
- 推荐优先用函数指针形式 deleter：
[](void* p) { free(p); }比[ctx](void* p) { free_with_ctx(p, ctx); }更轻量
复杂点在于：deleter 类型一旦确定，就绑定进模板实例，没法运行时切换。所以一开始选错，后面改起来牵连甚广。
