选 cli11。它持续更新、文档清晰、错误提示友好，原生支持 c++17 特性；cxxopts 停留在 c++11，长选项别名、子命令嵌套等场景报错晦涩，调试成本高。
CLI11 和 cxxopts 哪个更值得选？
选 CLI11。它不是“更强大”，而是更贴近真实开发中的维护节奏：持续更新、文档清晰、错误提示友好，且对 C++17 的结构化绑定、std::optional、std::span 支持直接；cxxopts 仍停留在 C++11 兼容层，遇到长选项别名、子命令嵌套、类型推导失败时，报错信息常是空指针解引用或模板实例化失败，调试成本高。
-
CLI11默认启用异常（可关），但解析失败时抛出CLI::ParseError，能直接拿到缺失参数名、非法值位置 -
cxxopts用parse()返回ParseResult，但校验逻辑分散在各处，比如count("flag")不等于has("flag")，容易漏判布尔开关是否被显式设为 false - 两者都不支持运行时动态注册选项（比如插件系统需后期注入参数），别指望靠它们做热加载
怎么写一个带子命令和默认值的 CLI11 解析器？
核心是分三步：声明 CLI::App 实例 → 添加选项/子命令 → 调用 parse()。别在构造时就传 argc/argv，留到最后一刻再解析，方便单元测试传 mock 参数。
#include <CLI/CLI.hpp>
int main(int argc, char** argv) {
CLI::App app{"My tool"};
int port = 8080;
std::string host = "localhost";
app.add_option("-p,--port", port, "Server port")->check(CLI::Range(1, 65535));
app.add_option("-h,--host", host, "Bind address");
<pre class='brush:php;toolbar:false;'>auto* serve = app.add_subcommand("serve", "Start server");
serve->add_flag("-d,--debug", "Enable debug log");
try {
app.parse(argc, argv);
} catch (const CLI::ParseError& e) {
return app.exit(e);
}
if (app.get_subcommand_name() == "serve") {
// 使用 port/host，检查 serve->get<bool>("debug")
}}
- 子命令必须用
add_subcommand()显式创建，不能靠字符串匹配模拟 -
check()是链式调用，不是独立函数；不加校验器时，非法数字会静默转成 0（比如--port abc→port == 0） -
get_subcommand_name()返回空字符串表示没匹配到任何子命令，不是nullptr
cxxopts 解析布尔选项为什么总得到 true？
因为 cxxopts 把 --flag false 当作两个独立 token：--flag 触发开关置 true，false 被丢弃。它不识别赋值语法（--flag=false 也不行），布尔选项只能靠出现与否判断。
立即学习“C++免费学习笔记（深入）”；
- 正确用法：声明为
bool flag = false;，然后add_options("flag", "help msg", cxxopts::value(flag)) - 错误写法：用
std::string接收再手动转 bool —— 这会导致--flag 0和--flag false都变成 true（cxxopts 把非空字符串全当 true） - 如果真需要显式传
true/false，得用std::string+ 手动解析，但这就丧失了布尔语义，也破坏了--flag/--no-flag的 POSIX 风格
为什么 CLI11 在 macOS 上解析中文路径会乱码？
不是编码问题，是 argc/argv 本身在 macOS 终端里就是 UTF-8 编码，但 CLI11 默认不做字符集转换，直接按字节处理。乱码通常出现在你把 std::string 值直接传给 fopen() 或 Qt 的 QFile 时——后者内部期望 CFString 或 UTF-16。
- CLI11 本身不处理宽字符，所有选项值都是
std::string；如果你需要 wchar_t 接口，得自己用std::mbstowcs()转（注意 locale 设置） - 更稳妥的做法：保持 CLI11 用
std::string，后续 I/O 层统一用 UTF-8 接口（如std::filesystem::path构造函数接受 UTF-8 string，C++17 起已保证） - 别试图在 CLI11 里 hook
parse()做全局编码转换——它的解析器不暴露 token 字节流，改不了
实际项目里，最常被忽略的是子命令的生命周期管理：CLI11 的 subcommand 指针在 parse() 后依然有效，但如果你在 lambda 里捕获它并延迟执行，而该 subcommand 已被 App 析构，就会 dangling pointer。别省那几行代码，用 app.get_subcommand("name") 按需取。
