一、"C++ 的魅力在于手动控制内存"

"智能指针是黑盒，C++ 的魅力在于可以直接控制内存的分配和释放。"

这句话你一定在某个技术群、某条知乎评论、或者某次 code review 中看到过。说出这句话的人，通常带着一种"真正的 C++ 程序员不用智能指针"的骄傲。

但这句话把两个不同的东西混为一谈了："控制力"和"手动执行"。

真正的控制力，是你知道每个对象归谁管、什么时候销毁。至于销毁的动作是谁执行——你的右手敲下 delete，还是 unique_ptr 的析构函数——那只是实现细节。

二、同一个项目，两种裸指针

在我最近修复的一个 MQTT 控制服务里，同一个代码库中同时存在两种裸指针用法：一种导致了真实的 bug，另一种是最佳实践。差别不在"裸不裸"，在于"所有权清不清晰"。

案例 A：脆弱的裸指针

AisNmeaParseApi.cpp 中解析 AIS 消息的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// ais_vdm_decode_payload — 解析函数
bool ais_vdm_decode_payload(const AisVdmSentence& vdm_sentence,
                            AisVdmMessage** message) {    // 双裸指针
    *message = nullptr;

    // ... 解析逻辑 ...
    switch (msg_type) {
        case 1: {
            auto* m = new AisVdmMessage_1_2_3();          // 手动 new
            if (!parse(s6, m)) { delete m; return false; } // 失败路径手动 delete
            *message = m;                                  // 所有权丢给调用方
            return true;
        }
        case 5: {
            auto* m = new AisVdmMessage_5();
            if (!parse(s6, m)) { delete m; return false; } // 又是手动 delete
            *message = m;
            return true;
        }
        // ... 还有 3 个 case，每个都要手写 delete ...
    }
}

// AisNmeaProcessor.cpp — 调用方
AisVdmMessage* msg_ptr = nullptr;
if (!ais_vdm_process_message(raw, &msg_ptr, _aisFrag))
    return false;
if (!msg_ptr)
    return false;
std::unique_ptr<AisVdmMessage> msg(msg_ptr);  // 调用方也觉得不安全，赶紧包一层

这段代码有 6 个 new，散布在 5 个 case 分支中。每个分支都有独立的失败路径，每条失败路径必须手写 delete。

如果一个新人加了一个 case 6，忘记在失败路径写 delete？泄漏。如果中间某处抛了异常？泄漏。调用方忘了包 unique_ptr？泄漏。调用方包了 unique_ptr，但中间某层函数提前 return 了？泄漏。

这不是"精细控制"，这是"人为制造泄漏点"。

修复后：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
bool ais_vdm_decode_payload(const AisVdmSentence& vdm_sentence,
                            std::unique_ptr<AisVdmMessage>& message) {
    message.reset();

    switch (msg_type) {
        case 1: {
            auto m = std::make_unique<AisVdmMessage_1_2_3>();
            if (!parse(s6, m.get())) { return false; }  // 失败，m 自动析构
            message = std::move(m);                      // 所有权显式转移
            return true;
        }
        // ... 其他 case 同理，不再需要手动 delete ...
    }
}

// 调用方
std::unique_ptr<AisVdmMessage> msg;
if (!ais_vdm_process_message(raw, msg, _aisFrag))
    return false;
// msg 直接可用，无需再包一层

所有权从创建点就用 unique_ptr 管理，在任何执行路径下都一致：成功 → 移动给调用方；失败 → 自动析构。

案例 B：安全的裸指针

同一个项目里，MainNode 的这几个裸指针完全没有问题：

1
2
3
4
5
class MainNode {
    BeiDou* _beidouDevice = nullptr;  // 指向北斗设备
    ZD* _zdDevice = nullptr;          // 指向 ZD 设备
    SSPC* _sspcDevice = nullptr;      // 指向 SSPC 设备
};

这些指针指向的是什么？通过 DeviceManager::getInstance().getDevice<T>(name) 获取的对象。追进去看：

1
2
3
4
5
6
7
8
9
10
template<typename T>
T* DeviceManager::getDevice(const std::string& device_name) {
    auto it = devices_.find(device_name);
    return dynamic_cast<T*>(it->second);  // it->second 是 Device*
}

// 注册时：
auto& inst = T::getInstance();  // Singleton<T> — 静态局部变量
Device* dev = &inst;            // 取静态对象的地址
devices_[device_name] = dev;

这些设备对象是 Singleton<T> 的静态实例，生命周期是整个程序。MainNode 只是"借用"它们来读取数据，不拥有、不负责销毁。

裸指针在这里是正确的——因为它准确传达了"非所有权引用"的语义。 如果换成 shared_ptr，反而会误导读者：难道 MainNode 参与了设备对象的生命周期管理？

三、真正的问题：你来回答

同一个项目，裸指针有时是 bug，有时是最佳实践。差别不在指针类型，在这一个问题：

这段代码里，谁拥有这个对象？

  • AisVdmMessage：decode_payload 创建，调用方接收。所有权从被调用方转移到调用方。所以应该用 unique_ptr 显式标注这个转移。

  • BeiDou 设备：Singleton<T> 拥有，DeviceManager 索引，MainNode 借用。MainNode 不拥有，所以裸指针。

你不需要在每一次写 new 的时候问自己"这里我该用 unique_ptr 还是裸指针"。你只需要问：谁创建、谁销毁、有没有共享。

如果这三个问题你能回答清楚，指针类型自然就明确了。

四、决策框架

你创建了对象？ 你负责销毁？ 别人也共享？ 用什么 例子
是 是 否 unique_ptr 工厂函数返回新对象，调用方独占
是 是 是 shared_ptr 多个模块持有同一配置对象
否 否 — 裸指针 / 引用 观察者模式、缓存指向静态单例的指针
是（特殊内存） 是 否 placement new / 自定义删除器 内存池、共享内存、GPU 显存
跨 DLL 边界 — — 裸指针 + 工厂销毁函数 ABI 兼容性要求

关键判断不是"这个指针类型叫什么"，而是"谁创建、谁销毁、有没有共享"。

框架的使用方法：

  1. 看一眼你的代码，找到所有 new。
  2. 问：这个 new 出来的对象，谁负责 delete？
  3. 如果答案"不明确"或"看情况"——那就是 bug 埋藏的地方。
  4. 如果答案明确——unique_ptr（独占）、shared_ptr（共享）、裸指针（借用），选哪一个自然就知道了。

五、"智能指针是黑盒"的幻觉

说 unique_ptr 是黑盒的人，通常有一个隐含假设：手动 new/delete 比 unique_ptr 更"可控"。

但实际项目里——

对象经历 3 层调用链，从 decode_payload 到 process_message 到 processRaw，每一层都可能提前 return、都可能抛异常、都可能被新来的同事插入一个分支。你觉得你能追踪每一条路径上的 delete？

unique_ptr 的析构是确定性的、可预测的——离开作用域就释放。 这等价于你在作用域末尾写了一个永远不会被跳过的 delete。这不是"黑盒"，这是"编译器帮你执行了你本来就应该写的 delete"。

编译器不会忘，你会。

六、C++ 真正的魅力

C++ 的魅力不是"可以手动管理每一字节"。

C++ 的魅力是：你可以选择用什么样的抽象来管理资源。

  • Rust 强制你使用所有权系统——unique_ptr 的 Rust 版本叫 Box，而且你没得选。
  • C 完全不管——你手上只有 malloc 和 free，爱怎么用怎么用。
  • C++ 在中间——给你 unique_ptr、shared_ptr、裸指针、placement new、自定义分配器，但让你自己选。

选择什么不反映你对语言的熟悉程度，反映你对正在解决的问题的理解深度。

用 unique_ptr 不是说"我不懂手动内存管理"，而是说"我分析了这段代码的所有权关系，结论是这个对象应该被独占拥有，所以我选择用 unique_ptr 来让编译器替我执行这件机械的事，把我的精力留给更重要的设计决策"。

C++ 不强迫你做对的事。它只是给你足够的工具，等你做错的时候，让 Valgrind 来告诉你。

七、一个简单的习惯

下次写 new 的时候，停一秒，回答三个问题：

  1. 谁拥有这个对象？（哪个模块、哪个类、哪个函数）
  2. 它什么时候被销毁？（请求结束？程序退出？引用计数归零？）
  3. 销毁操作由谁触发？是显式调用，还是自动析构？

如果你答不出第 1 个——停下来，先想清楚设计。
如果你答得出第 1 个但答不出第 2、3 个——用 unique_ptr，让编译器帮你答。
如果你全部答得出——裸指针还是智能指针，你自然知道。

这不是语法问题，是设计问题。