后端常遇到这类需求：某个能力已经有一个成熟的 CLI 工具（openssl、7z、ffmpeg、pdfcpu），但要把它变成程序里可调的能力。直觉是「找 SDK 静态链接」，但很多时候更稳的做法是「拉子进程 + 透传参数 + 收 stdout」。本文复盘 yyzTools（一套 Windows 桌面效率工具集）如何把 6 个第三方 CLI 当作「外部服务」编排，以及这套架构在依赖管理、版本绑定、安全审计上的取舍。适合做 CLI 封装、工具链集成、可信供应链的读者参考。
一、为什么不直接静态链接 SDK
yyzTools 需要这些能力：加解密（OpenSSL）、压缩（7-Zip）、音视频（FFmpeg）、图片（ImageMagick）、PDF（pdfcpu）、下载（Aria2）。每个都有 C/C++ SDK 可链。但全静态链接会撞上一组问题：
| 问题 | 表现 |
| 符号冲突 | 多个库都链 OpenSSL、zlib、libpng，符号打架 |
| 编译复杂度 | 每个库的 CMake、依赖树、交叉编译参数都要维护 |
| 版本绑死 | 升级某个库要重新编译主程序 + 全量回归 |
| ABI 风险 | 静态库的 ABI 变化可能踩崩主程序 |
| 安全审计 | 漏洞（CVE）来了，要重新编译重发，用户重装 |
对桌面客户端尤甚：用户装一次，主程序二进制里的静态库版本就冻结了。一个 OpenSSL CVE 出来，要重发整个程序让用户更新。
yyzTools 的选择是：这些能力不静态链接，而是拉起自带的 CLI 子进程。CLI 可执行文件独立放在 bin64/Platform/ 下，版本独立、升级独立、审计独立。
二、子进程透传的调用模型
统一模式，不管封装的是 openssl 还是 7z：
业务层（前端 / C++） -> 构造命令行参数（算法/输入/输出路径） -> CreateProcess 拉起 CLI 子进程 -> 子进程跑完，stdout 输出结构化结果 -> C++ 解析 stdout，包成 JSON { error, result, ... } -> 回业务层
几个工程要点：
2.1 参数透传，不做语义翻译
C++ 层不解析「sm4-cbc 是什么」「-gravity southeast 是什么」。它只负责把业务层给的算法名/参数拼到命令行，原样透传。这样 C++ 层不耦合具体算法语义--新增算法（比如 sha3）不用改 C++。
2.2 stdout 做结构化信道
子进程的成功结果走 stdout，C++ 读 stdout 拿到原始输出再包 JSON。错误走 stderr + exit code。好处是信道和调用语义分离：业务层拿到的永远是统一 JSON，不用管底下是哪个 CLI。
2.3 独立子进程独立失败
某个 CLI 崩了，exit code 非零，C++ 把它包成 error != 0 的 JSON 返回。主进程不受影响。这是子进程模型天然给的故障隔离，和静态链接里「一个库函数 segfault 整个进程挂」完全不同。
2.4 版本独立可验
每个 CLI 是独立的可执行文件，openssl version、ffmpeg -version 都能直接查。供应链审计时，列一遍 bin64/Platform/ 就知道每个组件的版本。比挖静态库符号表简单太多。
三、6 个 CLI 的封装要点
| CLI | 在 yyzTools 的角色 | 透传要点 |
openssl.exe |
哈希、加解密、密钥/IV 生成 | 算法名透传（enc/dgst），sm2/sm3/sm4 走 OpenSSL 3.5.7 原生 |
7z.exe |
压缩解压、更新包解压 | 透传压缩格式 + 算法，stdout 拿文件列表 |
ffmpeg.exe |
录屏编码、批量视频处理 | 透传编解码参数，进度走 stdout 解析 |
magick.exe |
批量图片处理 | 透传动作链（resize/convert/watermark） |
pdfcpu.exe |
批量 PDF 处理 | 透传动作（merge/split/watermark/encrypt） |
aria2c.exe |
下载管理 | 透传 URL + 多线程/续传选项，进度走 stdout |
统一模式：C++ 层是「参数拼装 + 进程拉起 + stdout 解析」三段式，不碰业务语义。这是这套架构能同时管 6 个完全不同领域的 CLI 的原因。
四、架构取舍
收益
- 升级零编译：FFmpeg 出新版，换
ffmpeg.exe文件即可，主程序不重编译。对桌面客户端，一次小更新就升了某个引擎。 - 故障隔离：CLI 崩了不牵连主进程，用户其他功能照用。
- 供应链透明：每个 CLI 版本独立可查，CVE 来了只换受影响的那个文件。
- 扩展成本低：加一个新 CLI（比如以后加
cwebp做 WebP 优化），照抄三段式封装，不用动主程序架构。 - 跨语言无感：CLI 是什么语言写的（C/Go/Rust）都无所谓，子进程接口是通用的。
代价
- 每次调用 fork 子进程：单次延迟比函数调用高（毫秒级）。对低频调用无所谓，对高频（每秒万次）不可行。
- 进程间通信开销：大输入走 stdin/文件，结果走 stdout，比内存调用慢。对大文件哈希、批量处理有体感影响。
- CLI 行为依赖：CLI 升级若改了参数语义或输出格式，C++ 的 stdout 解析要跟改。比静态库的 ABI 变化容易查（CLI 输出错了立刻看得见），但仍是要维护的耦合点。
- 进程生命周期管理：要管子进程超时、僵尸进程、取消。静态函数调用没这些事。
- 环境依赖：子进程依赖自带的可执行文件在位、可执行权限正确。打包时要带上全部 CLI。
五、和静态链接、gRPC 微服务的位置关系
这套架构在依赖管理光谱上的位置：
| 极端 | 静态链接 SDK | 子进程透传 CLI | gRPC 微服务 |
| 集成方式 | 编译期符号 | 运行时进程 | 网络远程调用 |
| 性能 | 最快（函数调用） | 中（fork + IPC） | 最慢（网络） |
| 升级成本 | 重编译 + 全量回归 | 换文件 | 重新部署服务 |
| 故障隔离 | 无（库崩进程崩） | 有（进程边界） | 强（网络边界） |
| 跨语言 | 编译期绑定 | 天然跨语言 | 天然跨语言 |
| 适用场景 | 高频核心能力 | 低频可信能力 | 跨进程/跨机能力 |
子进程透传是静态链接和微服务之间的中间档：要故障隔离和升级便利，但不要网络开销、不要服务化部署成本。对桌面客户端这种「单机、能力多、调用低频」的场景，位置刚好。
服务端也能找到对应：把某个第三方能力（比如文件转换、加解密合规）从主服务里拆出来做成独立可执行，主服务拉子进程调。这比微服务轻（不用部署/注册/熔断），比静态链接灵活（升级换文件）。
六、几个工程细节值得点出
6.1 stdout 要做结构化契约
CLI 的 stdout 默认是给人看的，不是给程序解析的。封装时要让 CLI 输出结构化（JSON 最好），或者用一个稳定的解析协议。yyzTools 的做法是 C++ 层负责把 CLI 的原始输出规整成统一 JSON 给业务层，业务层永远拿 { error, result }。
6.2 子进程超时与取消
子进程可能 hang（网络下载、大文件处理）。封装层要有超时杀进程的逻辑，不能让子进程无限跑。yyzTools 的下载、批量处理都有进度和取消，靠的是子进程可控 + 进度解析。
6.3 进程数控制
批量处理 200 张图，不能拉 200 个 magick 子进程。要排队、限并发。封装层管一个工作队列，控制同时在跑的子进程数。
6.4 错误语义归一
不同 CLI 的错误码不同（7z 的 exit code、ffmpeg 的返回值）。封装层要把「子进程失败」归一成统一的错误对象，业务层不用关心是哪个 CLI 报的。
七、小结
把第三方 CLI 当作「外部服务」用子进程透传封装，是静态链接和微服务之间的中间档架构。收益是升级零编译、故障隔离、供应链透明、扩展成本低；代价是单次调用开销、进程生命周期管理、CLI 输出契约维护。
适合的场景：能力多、调用低频、第三方有成熟 CLI、要快速跟进上游版本。yyzTools 把 6 个 CLI（openssl/7z/ffmpeg/magick/pdfcpu/aria2c）统一封装，是这个架构的一个完整样本。对做工具链集成、可信供应链、合规能力封装的后端，这套取舍值得参考。
核心判断标准：这个能力是高频吞吐核心，还是低频可信外围。前者静态链接或微服务，后者子进程透传。别把低频外围能力搞成重编译地狱。
