argparse适合简单脚本，click更适合产品化CLI工具；前者轻量标准但子命令难维护，后者功能丰富但学习成本略高，选择取决于使用者、使用频率及扩展需求。
argparse 适合快速写脚本，但嵌套子命令难维护
当你只需要一个简单命令行工具，比如 python backup.py --source /data --dest /backup，argparse 足够轻量、标准库自带、不用装依赖。但一旦要支持多级子命令（如 git commit、git push），就得手动搭 add_subparsers() 结构，参数校验、帮助文本对齐、共享选项（如 --verbose）都要自己缝合，容易写出重复又难 debug 的逻辑。
常见错误现象包括：error: too few arguments 却找不到哪层 parser 漏了 required=True；子命令帮助页里父命令的描述没继承；set_defaults(func=...) 回调函数签名不一致导致运行时报 TypeError。
- 用
add_subparsers(dest='command')时，务必给每个子解析器显式设help=，否则--help不显示子命令列表 - 共享参数（如
--debug）建议在父 parser 上定义，再传给add_subparsers()的parser_class参数定制子解析器基类 - 避免在
set_defaults()里直接调函数，应只存函数引用，等args.func(args)统一触发
click 更适合 CLI 工具产品化，但学习成本略高
click 把命令组织成装饰器链，天然支持嵌套、参数类型自动转换、选项前缀统一处理（如 --dry-run → dry_run 变量名），还内置颜色、分组、shell 补全。它更适合交付给终端用户长期使用的工具，比如 pip 或 poetry 那种体验。
但要注意：它的“魔法”来自装饰器堆叠，调试时容易迷失在哪一层改了 ctx；默认把 -h 和 --help 都启用，和某些旧脚本习惯冲突；且不兼容 argparse 的 Namespace 对象，迁移老代码需重写入口逻辑。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
立即学习“Python免费学习笔记（深入）”；
- 用
@click.group()定义主命令，子命令用@main.command()，共享选项用@main.pass_context+ctx.ensure_object(dict) - 参数类型别硬写
str或int，优先用click.Path(exists=True)、click.Choice(['a', 'b'])，能提前拦截非法输入 - 如果需要和 argparse 生态集成（比如已有
ArgumentParser实例），别强转，直接用click.Command手动构造，而非依赖自动桥接
性能差异几乎可忽略，但启动开销有区别
单次执行下，argparse 启动快几毫秒——毕竟纯 Python 标准库；click 首次导入稍慢（约 10–20ms），主要花在装饰器注册和类型系统初始化上。但实际 CLI 工具多数是 I/O 密集型（读文件、发请求），这点差异毫无感知。
真正影响体验的是错误反馈速度：argparse 解析失败时抛 SystemExit 并打印帮助，用户得扫完整屏；click 默认只报错不打帮助，加 no_args_is_help=True 或自定义异常处理器才能对齐习惯。
- 生产环境建议都加
try/except SystemExit包裹主入口，统一日志和退出码 - 别用
click.echo()直接打调试信息，它受--quiet控制；临时调试用print()更可靠 - 如果工具要嵌入其他 Python 进程（如 pytest 插件），优先选
argparse，避免click的上下文栈干扰
别纠结“该用哪个”，先想清楚谁在用、用几次
内部运维脚本、CI 中跑一次就完事的工具，argparse 省心；要发 PyPI、写文档、支持 tab 补全、甚至未来做 Web API 封装的，click 的结构延展性明显更强。最常被忽略的一点是：两者都不擅长动态生成选项（比如从远程 API 加载命令列表），这种场景得自己在 callback 或 action 里捞数据，别指望框架自动搞定。
