应优先使用 argparse 而非手动解析 sys.argv，因其能规范处理位置参数、选项组合、类型校验、帮助信息等；手动解析易出错且难维护，仅适用于极简临时脚本。
直接用 argparse，别碰 sys.argv 手动解析，除非你明确知道在做什么、且参数极简。
为什么不用 sys.argv 自己切字符串
手动处理 sys.argv 看似简单，实际很快会失控：位置参数和选项混在一起、短选项连写（如 -abc）要拆解、值是否跟在空格后、引号包裹的含空格参数会被截断、帮助信息得自己拼……sys.argv[1:] 只是原始输入流，不是参数结构。
- 错误现象：
python script.py --input file.txt --verbose中，若没检查--input后是否有值，sys.argv.index('--input') + 1可能越界或取到下一个 flag - 场景局限：仅适合单参数、无 help、无类型校验、不需兼容 POSIX 风格的脚本（比如临时 debug 工具）
- 建议：真要用，至少先
import shlex拆分命令行，再按规则遍历；但不如直接上argparse
argparse 是 Python 标准答案，但要注意几个关键参数
argparse 覆盖绝大多数 CLI 场景，关键是把参数“声明清楚”，而不是“逻辑写清楚”。它的核心不是解析动作，而是定义契约。
-
add_argument('--host', default='localhost')：显式声明默认值，别依赖函数内硬编码 -
type=int或自定义函数（如type=valid_port），比事后int(args.port)报错更友好 -
nargs='*'（零或多个）、nargs='+'（一个或多个）、nargs='?'（可选单个）——不设nargs默认是 1 个，别想当然 -
action='store_true'用于布尔开关（如--dry-run），别写成type=bool——后者会把任何非空字符串转为True - 子命令用
add_subparsers()，避免一堆if args.cmd == 'x'嵌套
需要配置文件 + 命令行混合时，别让 argparse 背锅
argparse 不负责读配置文件。常见模式是：先解析出 --config 参数，再用 yaml.load 或 json.load 读配置，最后用命令行参数覆盖配置值。顺序不能反。
立即学习“Python免费学习笔记（深入）”；
- 错误做法：把配置文件字段也注册成
add_argument，导致 help 输出混乱、类型校验重复 - 推荐流程：
parser.add_argument('--config', type=str)→ 解析出 config 路径 → 加载配置 dict → 再调用parser.parse_args(Namespace=namespace)覆盖默认值 - 注意：配置文件里布尔值常是
yes/no或true/false字符串，别直接塞给action='store_true'的参数 - 性能影响：配置文件加载本身不慢，但若支持多级继承（如 base.yml + env.yml），解析逻辑就得自己控制，
argparse不介入
第三方库如 click 或 typer 适合什么情况
当 CLI 要求高可维护性、自动补全、嵌套命令组、或与 Web 框架（fastapi）共享类型定义时，click 和 typer 更省力。但它们不是用来替代 argparse 的“更高级版本”，而是不同设计哲学。
-
click：装饰器驱动，适合已有函数想快速暴露为 CLI，例如@click.command(); def deploy(env):；缺点是调试时参数绑定链略深 -
typer：基于类型提示自动生成 CLI，def main(name: str, age: int = 0)直接变成带类型校验的命令；但 Python 3.6+ 强依赖，且对复杂类型（如枚举、嵌套 pydantic model）支持才真正体现价值 - 兼容性提醒：
click在 windows 下 ANSI 颜色输出默认关闭，typer的自动补全需额外装typer-cli；而argparse无此问题 - 别为了“时髦”引入——如果只有 3 个参数、无子命令、不发 pip 包，
argparse更轻、更易 grep、更少隐式行为
参数解析真正的难点从来不在“怎么拿到值”，而在于“怎么让使用者不困惑”——help 是否准确、报错是否指向真实原因、默认值是否符合直觉、长选项名是否和文档一致。这些细节，argparse 提供了地基，但填坑还得靠人盯住每个 help= 字符串和 default= 的取值。