argparse比sys.argv更专业，因其自动生成帮助文档、自动类型检查、支持默认值和子命令，而sys.argv需手动处理参数校验、类型转换和错误提示。
直接结论：用 sys.argv 是自己搭脚手架，用 argparse 是拎包入住——前者省事在“写得快”，后者省事在“改得稳、用得清、错得明”。
什么时候该坚持用 sys.argv
只满足以下全部条件时才值得手动解析：
- 脚本生命周期短（比如临时 debug 工具、CI 中一行即弃的 wrapper）
- 参数固定且少于 3 个（如 python sync.py src/ dst/ --dry-run 这种伪选项，其实只是约定俗成的字符串判断）
- 不需要类型校验（所有值都当字符串用，或你敢保证传进来的 sys.argv[2] 一定是数字）
- 不对外发布，也不打算加 help 提示或做参数合法性兜底
- 你愿意为每个 if arg == '--verbose' 后面手动补 try/except ValueError 和缺失检查
argparse 的 add_argument 参数不是可有可无的装饰
很多初学者以为 type=int 只是“顺手转下类型”，其实它绑定了三件事：
- 解析阶段自动调用 int()，失败直接抛 argparse.ArgumentTypeError，不让你落到业务逻辑里再处理
- 错误信息自带上下文，比如传了 --size abc，会报 error: argument --size: invalid int value: 'abc'，而不是 ValueError 加 traceback
- 与 default、choices、required 协同工作：比如 choices=[1, 2, 4] 和 type=int 一起用，才能真正拦截非法值；单用 choices 但没设 type，传入字符串 '2' 会因类型不匹配而失败
- nargs 控制接收几个值：设为 '+' 表示至少一个，'*' 表示零或多个，'?' 表示可选一个（此时 const 和 default 才有意义）
常见错误：把 sys.argv 当 argparse 用，又不敢全信 argparse
这两类坑最典型：
- 混用两者：比如先用 argparse 解析主参数，再手动遍历 sys.argv 去找某个未声明的标志位——这会让 argparse 的互斥组（add_mutually_exclusive_group）、子命令（add_subparsers）完全失效
- 忘记 sys.argv[0] 是脚本名：写 for arg in sys.argv: 导致第一个元素被当成参数处理，结果脚本名被当参数传给逻辑，引发路径拼接错误或空值异常
- 把 argparse 当万能胶水：比如用 action='store_true' 定义 --debug，却在代码里写 if args.debug == 'True': ——它实际是布尔值 True 或 False，不是字符串
- 不设 dest 又重命名：比如 add_argument('-f', '--file-path')，默认 dest 是 file_path（下划线），但你代码里写 args.filepath 就取不到值
复杂点往往藏在“默认行为”里
argparse 默认开启 allow_abbrev=True，所以 --ver 会被识别为 --verbose；线上工具建议显式关掉：ArgumentParser(allow_abbrev=False)，避免用户输错缩写时静默匹配成功。
另外，sys.argv 在 Windows 和 Linux 下对空格、引号的处理一致，但 argparse 的 nargs='*' 遇到带空格的参数（如 --msg "hello world"）必须加引号，否则 shell 就拆开了——这不是 Python 的问题，是命令行解析链路的共性，但新手常归咎于模块本身。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
