argparse 最佳实践在于设计先行而非语法堆砌：需明确用户场景与扩展需求，规避子命令嵌套混乱、help错位、type校验粗糙等问题；应显式设required=false并手动检查subcommand，用dest命名子命令，避免参数名冲突，善用action替代type实现计数、分级、自动加载等逻辑；入口函数须分离解析与业务，便于测试与维护。
argparse 是 Python CLI 工具最常用、最稳的参数解析模块，但直接上手写 argparse.ArgumentParser() 容易陷入“能跑但难维护”的陷阱——比如子命令嵌套混乱、帮助信息错位、类型校验靠 type=int 却不报具体错误、甚至把 default 和 const 搞混。
真正卡住人的从来不是语法，而是设计时没想清：这个 CLI 到底是给谁用？要不要支持 shell 补全？要不要和日志/配置文件联动？这些决定了你该不该用 argparse，还是换 click 或 typer。
为什么 add_subparsers() 一用就报 error: the following arguments are required:
这是 argparse 最典型的“静默陷阱”：当你调用 add_subparsers(required=True)（Python 3.7+ 默认行为），但用户只输主命令没输子命令，parse_args() 就会直接报错，且错误信息里不提示“你漏了子命令”，只说某个子命令下的参数缺失。
-
解决方法不是关掉
required，而是显式传required=False，再手动检查args.subcommand is None - 子命令的
parser必须用dest命名，否则args里压根没有字段存子命令名 - 别在子命令 parser 上重复定义和父 parser 同名的参数（比如都加
--verbose），argparse 不合并，会覆盖或冲突
type 参数不如 action 灵活，但很多人硬扛不用 action
type 只负责把字符串转成目标类型，失败就抛 ArgumentTypeError，错误信息干巴巴；而 action 能接管整个赋值逻辑，比如实现“多次出现累加”“存在即 True”“路径自动展开”。
- 要支持
mytool --flag --flag --flag计数？用action='count'，别写type=int+ 手动计数 - 要支持
mytool --debug --verbose分级？用action='store_const'配合const和dest - 要把
--config path.yaml自动读取并解析？自定义action类，重写__call__方法，在里面做yaml.safe_load(open(value))
CLI 的入口函数别直接塞业务逻辑，先过 main() 再分发
很多教程教人把所有代码堆在 if __name__ == '__main__': 里，结果一加测试就抓瞎——没法 mock 参数、没法测分支路径、没法复用核心函数。
- 把参数解析和业务逻辑彻底分离：一个函数只做
parse_args()并返回Namespace，另一个函数接收这个Namespace并执行 - 入口点（entry point）保持极简：
if __name__ == '__main__': args = parse_arguments() main(args) - 这样单元测试只需构造
Namespace实例，不用伪造sys.argv，也不用 patchsys.exit
subparsers 嵌套超过两层，就该考虑拆成独立脚本；比如 help 文字里出现“请参考 config.toml 格式”，说明参数体系已经超出了 CLI 自解释能力——这时候加个 mytool schema 子命令，比写十行注释管用。 
