函数指针无法承载私有状态、初始化参数及析构逻辑，故不能替代算法模块；真正可插拔需依托多态对象，如std::unique_ptr<AlgorithmBase>或原子化的std::shared_ptr<AlgorithmBase>实现安全热替换与类型安全。
为什么不能直接用函数指针替代算法模块
函数指针只能绑定固定签名的函数，一旦算法需要访问私有状态（比如缓存、配置、上下文），它就无能为力。更关键的是，不同算法可能需要不同的初始化参数或生命周期管理——函数指针无法承载析构逻辑。真正可插拔的核心不是“能调用”，而是“能构造、能销毁、能隔离状态”。
所以实际项目里，std::function 或裸函数指针只是表层接口，底层必须靠多态对象承载。
用基类指针 + std::unique_ptr 实现安全插拔
定义统一接口基类，所有算法实现继承它；运行时通过 std::unique_ptr<AlgorithmBase> 持有具体实例。这样既能多态调用，又自动管理内存，避免裸指针悬挂。
常见错误现象：delete p; p = nullptr; 手动管理易漏、易重复释放；或传入栈对象地址导致悬垂指针。
立即学习“C++免费学习笔记（深入）”；
- 基类必须有
virtual ~AlgorithmBase() = default;，否则unique_ptr析构时不会调用子类析构函数 - 算法工厂函数返回
std::unique_ptr<AlgorithmBase>，不暴露原始指针 - 若需运行时切换算法，直接赋值新
unique_ptr即可，旧实例自动析构
class AlgorithmBase {
public:
virtual ~AlgorithmBase() = default;
virtual int process(const std::vector<int>& data) = 0;
};
<p>class FastSort : public AlgorithmBase {
std::string config<em>;
public:
explicit FastSort(const std::string& cfg) : config</em>(cfg) {}
int process(const std::vector<int>& data) override { /<em> ... </em>/ }
};</p><p>// 工厂函数
auto make_algorithm(const std::string& name) -> std::unique_ptr<AlgorithmBase> {
if (name == "fast") return std::make_unique<FastSort>("optimal");
if (name == "safe") return std::make_unique<SafeSort>("debug");
return nullptr;
}如何支持热替换而不中断调用
直接赋值 std::unique_ptr 会导致短暂空状态，如果算法被多线程并发调用，可能触发空指针解引用。真实场景中，需要用原子指针或读写锁保护访问点。
推荐做法：用 std::shared_ptr<AlgorithmBase> + 原子交换。老实例在所有当前调用结束后自然销毁，新实例立即生效。
- 把持有者改为
std::atomic<std::shared_ptr<AlgorithmBase>> - 切换时用
exchange()，保证原子性 - 注意：
shared_ptr的线程安全仅限于控制块操作，对象内部仍需自行同步
错误示例：algo_ptr_.store(std::make_shared<NewAlg>()); —— 非原子赋值，可能让其他线程读到中间态空指针。
为什么不用 void* 或 reinterpret_cast 实现“通用指针”
有人试图用 void* 存算法对象地址，再靠外部约定强转回具体类型。这在跨编译单元、启用 LTO 或不同 ABI 时极易崩溃——vtable 偏移、内存布局、RTTI 信息全部丢失。
更隐蔽的问题是：你无法在运行时验证指针是否指向合法的算法实例。而虚函数调用失败会直接 crash，没有 fallback 机会。
真正可维护的插拔，依赖的是明确的接口契约和类型安全的指针语义，不是靠绕过类型系统。
复杂点在于：算法模块常需加载动态库（.so/.dll），这时得配合 dlopen/LoadLibrary 和符号解析，但指针本身仍应是 shared_ptr<Interface>，不能退化为 void*。
