动态库适用于热更新、内存共享、插件化及跨版本部署场景，但需注意函数签名一致、abi兼容、符号导出规范和rpath配置，否则易引发加载失败或段错误。
需要频繁更新核心逻辑的项目
比如支付网关、风控引擎或协议解析模块，这些功能常因合规、安全或业务规则变动而需热更新。动态库允许你只替换 libpayment.so 或 libprotocol.so，无需重新编译整个服务进程。但要注意：函数签名不能变，否则 dlopen 加载时会失败，或者运行时调用 dlsym 返回 NULL。
多进程共享同一套计算逻辑的场景
典型如图像处理服务集群——多个 worker 进程同时调用相同的滤镜算法或编解码逻辑。用动态库（libimage.so）可让内核只加载一份代码页到内存，减少 RSS 占用。若改用静态库，每个进程都会复制一份目标代码，内存开销翻倍。不过得确保所有进程都使用相同 ABI 版本，否则 ldd 检查会报 version `GLIBC_2.34' not found 类错误。
插件化架构或模块热插拔需求
像日志分析平台支持按需加载不同解析插件（plugin_json.so、plugin_avro.so），这类设计依赖 dlopen/dlsym 运行时加载。关键点在于：插件必须导出统一符号（如 init_plugin、parse_record），且头文件中用 extern "C" 防止 C++ 名字修饰；否则 dlsym 找不到符号，返回空指针却无明确错误提示。
部署环境受控、但目标机器 GLIBC 版本不统一
如果你的程序要跑在 CentOS 7（GLIBC 2.17）和 Ubuntu 22.04（GLIBC 2.35）上，直接链接新版动态库会导致 undefined symbol: __libc_malloc。解决方案不是降级编译环境，而是用 -Wl,-rpath='$ORIGIN' 把库路径硬编码进可执行文件，并把 libxxx.so 和主程序一起打包。这样既避开系统路径污染，又避免 LD_LIBRARY_PATH 设置失误导致的 error while loading shared libraries。
