热更新本质是运行时替换函数指针，需将业务逻辑封装为可卸载模块，通过dlopen/dlsym加载extern "C"导出的纯函数，并用std::atomic安全切换指针；严禁模块持有全局状态或跨DLL内存分配，状态须由主程序统一管理并传入。
热更新的本质是“替换运行时的业务函数指针”
服务端不重启就能换规则，核心不是 magic，而是把业务逻辑封装成可卸载、可重载的模块，再用函数指针或虚函数表动态切换。C++ 没有原生热重载支持，必须自己管理模块生命周期和符号绑定。常见错误是直接 dlopen 后反复 dlsym 调用旧地址，导致 crash——因为旧 SO 卸载后，其代码段内存已被回收，指针变野指针。
关键约束有三点：SO 文件必须位置无关（-fPIC）、导出符号需 extern "C" 避免 name mangling、模块内不能持有全局/静态对象（尤其带构造/析构的），否则卸载时行为未定义。
用 dlopen + dlsym 实现规则函数的原子切换
最轻量、最可控的方式：把每条规则抽象为一个纯函数，例如 bool check_user_rule(const User& u)，在 SO 中实现并导出。主程序通过句柄管理当前生效的规则模块。
- 加载新 SO 前，先调用旧模块的
cleanup()（如有），再dlclose()；否则可能因引用计数未清导致卸载失败 - 新 SO 加载成功后，立刻用
dlsym(handle, "check_user_rule")获取函数指针，**不要缓存 handle 本身用于后续调用**——handle 只是加载句柄，真正要调的是函数指针 - 切换函数指针必须是原子操作：用
std::atomic_store_explicit(¤t_checker, new_fn, std::memory_order_release)，读取侧用std::atomic_load_explicit(¤t_checker, std::memory_order_acquire) - 避免在 SO 中调用主程序的非稳定接口（如未声明为
extern "C"的 C++ 成员函数），容易因 ABI 不一致崩溃
如何安全处理规则模块里的状态和依赖
热更新最常崩在状态迁移上。比如旧规则里有个 static std::unordered_map<int, RuleConfig> cache，新 SO 加载后这个 map 还在旧地址，但新代码试图访问它就会 segfault。
立即学习“C++免费学习笔记（深入）”；
正确做法只有一条：所有状态必须由主程序持有并传入规则函数，规则 SO 是纯函数式、无状态的。
- 主程序维护
RuleContext结构体，包含配置、缓存、日志器等，通过参数传给check_xxx(..., const RuleContext& ctx) - 若规则需要初始化（如加载配置文件），提供单独的
init_context(RuleContext*)函数，在 SO 加载后立即调用，且该函数不得分配长期存活的静态资源 - 禁止在 SO 中使用
new/malloc分配跨模块生命周期的内存——主程序无法安全free它；如需堆内存，统一由主程序提供 allocator 接口
为什么不用 std::filesystem::last_write_time 做自动热检
很多方案用文件时间戳轮询触发 reload，看似简单，实际问题一堆：
- Linux 下 NFS 或容器挂载卷中
last_write_time可能不更新或延迟，导致漏更或误更 - 写入 SO 文件是覆盖操作，
cp new.so old.so过程中存在短暂的“半截文件”状态，dlopen会失败甚至卡死线程 - 没有版本校验，一旦新 SO 编译出错（如符号缺失），服务直接 fallback 失败，而不是保留旧逻辑
更稳的做法是主程序暴露 HTTP 管理端点（如 POST /rules/reload?so_path=/opt/rules/v2.so），由运维人工触发，并返回明确的成功/失败原因（如 "symbol 'validate_order' not found"）。自动检测只适合开发环境，生产必须可控。
真正的难点不在加载，而在确保新规则语义兼容、状态零丢失、并发调用不撕裂——这些都得靠设计约束，而不是靠工具链自动解决。
