用 std::string_view 切分参数并手动分组最可控，因标准库无内置子命令解析；需从 argv+1 遍历识别命令与参数，统一用 std::span 传递子命令专属参数，避免 getopt_long 等工具的边界缺失问题。
用 std::string_view 切分参数再手动分组最可控
标准库没有内置子命令解析，main(int argc, char* argv[]) 给你的只是一维数组。想实现 git commit -m "msg" 这种结构，必须自己识别哪个是主命令、哪个是子命令、哪些属于子命令的选项——靠切分和状态机比硬套第三方库更轻量、更易调试。
常见错误是过早把整个 argv 转成 std::vector<:string></:string> 再做模糊匹配，结果空格嵌套、引号转义、短选项合并（如 -la）全得自己补逻辑，反而更乱。
- 从
argv + 1开始遍历，跳过程序名 - 遇到第一个不以
-开头的字符串，记为command；后续直到下一个非选项字符串前，都归入该命令的参数列表 - 选项（
-f、--file）统一收集到全局或当前子命令的std::map<:string_view std::string_view></:string_view>中，值可能是下一个参数，也可能隐含（如-v） - 用
std::string_view避免拷贝，尤其处理长路径或大参数时明显省开销
getopt_long 不适合子命令场景
它设计目标是单命令多选项，碰到 mytool sync --dry-run upload file.txt 这种结构会直接把 upload 当成 sync 的选项值，然后卡在 file.txt 上报错 unrecognized option。
根本原因是 getopt_long 没有“命令边界”概念，所有参数都被它按固定规则扫一遍，子命令名被当成非法选项拦截了。
立即学习“C++免费学习笔记（深入）”；
- 若坚持用
getopt_long，只能先人工截出子命令段（比如找到第一个非选项后停止），再对剩余部分重新调用getopt_long——但这就等于自己实现了外层分组逻辑 -
getopt系列不处理引号包裹的含空格参数（如"hello world"），shell 已拆解，但 c++ 层看不到原始引用信息 - windows 下
getopt非标准，需额外移植，跨平台成本高
子命令注册表用 std::unordered_map + 函数指针足够
不需要模板元编程或宏展开，一个简单映射表加明确的函数签名就能支撑多数工具需求。关键是让每个子命令函数接收统一的参数视图，而不是裸指针数组。
容易踩的坑是把参数解析和业务逻辑耦合太紧，比如在 commit() 里又写一遍 if (arg == "-m")，导致重复逻辑、难以复用。
- 定义统一接口：
int subcmd_func(std::span<const std::string_view> args)</const>，args是该子命令专属参数（不含命令名本身） - 注册时用
commands["commit"] = commit;，运行时查表调用，失败则报unknown command: xxx - 子命令函数内部再用轻量解析（如
std::find找-m，或简单循环）——此时范围小、语义明确，不易出错 - 避免用
std::function包装带捕获的 Lambda，增加二进制体积且无必要
引号和空格参数在 C++ 层无法还原原始形式
这是 shell 的责任，不是你的问题。linux/macos 下，./tool run "foo bar" 'baz qux' 传入 argv 的已经是两个独立字符串："foo bar" 和 "baz qux"（引号已被 shell 剥离）。你看到的就是最终形态，无需、也无法“解析引号”。
真正要防的是用户绕过 shell 直接调用（如 execve 传入未拆分字符串），但这种属于非标准使用，不在常规命令行工具保障范围内。
- 唯一需要主动处理的是反斜杠转义（如
file name.txt），但现代 shell 通常已处理，C++ 层一般忽略 - 如果真要支持 Windows 命令行特殊规则（如
^转义），应单独封装解析器，且仅在_WIN32下启用 - 测试时用真实 shell 调用（
bash -c './tool ...'），别用 ide 的“程序参数”框模拟，那里的行为和 shell 不一致
事情说清了就结束。子命令解析的核心不是找轮子，而是守住“谁负责切分、谁负责解释、谁负责执行”这三层边界。越早把参数按语义归组，后面就越少掉进选项透传、上下文丢失的坑。