10. 共享库实战：日志库案例、配置解析库案例、插件架构实现、热更新技术
好，咱们今天聊点实在的。前面几章把共享库的原理、编译、链接都捋了一遍，但说实话，光懂理论没用。你得真刀真枪地干过，才知道坑在哪。
我个人习惯，学一个新东西，一定要拿它做点能跑的东西出来。所以这一章，我挑了四个最典型的实战场景：日志库、配置解析、插件架构、热更新。这四个场景，基本覆盖了共享库在日常开发中80%的用法。
10.1 日志库案例：从简单到可插拔
日志库，每个项目都得有。但很多人的日志库是写死的——编译时决定输出到文件还是终端，运行时改不了。这其实很蠢。
我建议用共享库来实现日志后端。什么意思呢？就是你的日志框架只定义接口，真正的输出逻辑放在.so里。运行时你想换文件输出、网络输出、甚至Kafka输出，换个.so就行，主程序不用重新编译。
来看一个最简单的接口定义：
// log_interface.h
typedef void (*log_write_fn)(const char* msg, int level);
typedef struct {
log_write_fn write;
const char* name;
} log_backend_t;
extern log_backend_t* get_backend(void);然后你编译两个.so：一个写文件，一个写终端。主程序在启动时用dlopen加载其中一个。切换日志后端，就是改个配置文件的事。
小技巧：我在项目中遇到过日志库崩溃导致主程序挂掉的情况。后来强制要求日志库的.so里不能有全局锁，所有状态通过参数传入。这样即使日志库挂了，主程序还能继续跑。
10.2 配置解析库案例：JSON vs INI vs YAML
配置解析，说白了就是把文本变成内存里的结构体。但问题是，不同项目用的格式不一样。有的用JSON，有的用INI，有的用YAML。
你不可能在代码里写死一种格式。万一客户说「我们只用YAML」，你怎么办？重写？
用共享库就简单了。定义一个统一的配置解析接口：
// config_parser.h
typedef struct {
int (*parse)(const char* path, void* out);
void (*free)(void* config);
} config_parser_t;
config_parser_t* load_parser(const char* format);然后为每种格式编译一个.so。主程序根据配置文件里的format=json或format=yaml，动态加载对应的解析器。
嗯，这里要注意：不同解析器返回的结构体可能不一样。我的做法是统一用键值对表（key-value table），解析器只负责把文件转成这张表，主程序再查表取值。这样接口就干净了。
避坑指南：我曾经在配置解析库的.so里用了全局变量缓存解析结果，结果多线程环境下出了诡异的内存泄漏。后来所有状态都通过参数传递，再也不碰全局变量了。
10.3 插件架构实现：让程序长出自定义能力
插件架构，是共享库最经典的应用场景。你想想看，一个程序发布后，用户想加个新功能，你不可能每次都重新编译发布吧？
插件架构的核心就三点：
- 定义插件接口：头文件里声明插件必须实现的函数
- 动态加载：主程序在运行时扫描某个目录，用
dlopen加载所有.so - 统一注册：每个.so里有一个初始化函数，把插件信息注册到主程序
我做过一个图像处理程序，核心功能只有缩放和裁剪。用户想加滤镜？写个.so放到plugins目录，重启程序就能用。后来这个程序卖了上百份，全靠插件生态撑起来的。
一个典型的插件接口长这样：
// plugin.h
typedef struct {
const char* name;
const char* version;
int (*init)(void);
int (*process)(void* input, void* output);
void (*cleanup)(void);
} plugin_t;
// 每个.so必须导出这个符号
extern plugin_t* plugin_info(void);核心要点：插件接口一定要稳定。一旦发布，就别改了。否则用户升级插件时发现接口变了，你的客服电话会被打爆。
10.4 热更新技术：不停机换代码
热更新，说白了就是程序跑着跑着，你把某个.so文件换了，然后程序自动加载新版本。这在游戏服务器、金融交易系统里特别常见。
原理其实不复杂：
- 主程序定期检查.so文件的修改时间
- 发现变了，调用
dlclose卸载旧库 - 再调用
dlopen加载新库 - 更新函数指针，指向新库里的函数
但坑很多。我一个个说：
- 符号冲突：旧库和新库如果用了相同的全局符号名，
dlopen可能会返回旧库的地址。解决办法是编译时加-fvisibility=hidden，只暴露必要的符号。 - 内存泄漏：旧库卸载时，如果还有线程在执行库里的函数，直接
dlclose会导致崩溃。你得先确保所有线程都退出库函数了，再卸载。 - 状态迁移：旧库里的全局状态怎么迁移到新库？我的做法是：所有状态都放在主程序分配的内存里，库函数只操作传入的指针。这样换库时状态自然就保留了。
血的教训：我曾经在金融交易系统里做热更新，没处理好线程同步，结果旧库卸载时一个线程还在执行交易逻辑，直接导致订单数据错乱。那次事故让我明白：热更新不是简单的dlopen/dlclose，你得有完整的生命周期管理。
10.5 本章知识体系
下面这张图，把四个实战场景的核心逻辑串起来了。你看一眼，心里就有谱了。
这四个场景，其实都围绕一个核心：运行时多态。编译时你不知道具体用哪个实现，运行时才决定。这就是共享库最大的价值。
好了，这一章的内容就到这。你把这四个案例自己动手实现一遍，共享库这块基本就吃透了。下一章咱们聊聊更进阶的话题——共享库的性能优化和调试技巧。