sys.argv 是 Python 启动时从操作系统获取的原始字符串列表，仅含脚本路径和未解析参数，缺乏类型转换、格式校验、选项处理等能力，直接使用易导致崩溃或静默失败。
sys.argv 是什么，它为什么不能直接当参数解析器用
sys.argv 只是 Python 启动时从操作系统拿到的一串原始字符串列表，sys.argv[0] 是脚本路径，后面才是你敲的参数。它不做任何类型转换、不校验格式、不处理短选项（如 -v）或长选项（如 --verbose），更不会帮你区分位置参数和关键字参数。直接基于它写逻辑，很容易在参数缺失、类型错、顺序乱时崩溃。
常见错误现象：IndexError: list index out of range（访问 sys.argv[1] 但没传参）、ValueError（想转 int 却传了字母）、脚本静默失败却没提示用户怎么用。
- 永远先检查
len(sys.argv)是否满足最低参数数量，而不是直接索引 - 所有需要类型转换的地方（比如数字、路径），必须用
try/except包裹，且给出明确错误信息 - 不要把帮助信息硬编码在异常处理里——用户输错参数时，应该打印用法并退出，而不是抛 traceback
手动校验 sys.argv 的典型写法（带异常捕获和友好退出）
如果你确实只需要简单场景（比如一个输入文件路径 + 一个数字选项），手动处理比引入 argparse 更轻量。关键是把“参数合法性检查”和“错误响应”分离清楚。
import sys
<p>if len(sys.argv) < 3:
print(f"用法: {sys.argv[0]} <输入文件> <重复次数>")
sys.exit(1)</p><p>input_file = sys.argv[1]
try:
repeat_times = int(sys.argv[2])
except ValueError:
print(f"错误: <重复次数> 必须是整数，得到 '{sys.argv[2]}'")
sys.exit(2)</p><h1>后续逻辑...</h1>-
sys.exit(1)和sys.exit(2)不只是退出，还向 shell 返回不同状态码，方便上游脚本判断失败类型 - 不要用
print("错误") + raise SystemExit，直接sys.exit()更清晰 - 如果参数是路径，建议紧接着用
os.path.exists(input_file)检查，否则等到真正打开时才报错，堆栈更深、定位更难
什么时候该果断放弃 sys.argv，换 argparse
一旦出现以下任一情况，手写校验就容易漏掉边界、维护成本陡增：--output 和 -o 都要支持、参数有默认值、需要自动生成帮助文本、支持子命令（如 tool init / tool build）。
立即学习“Python免费学习笔记（深入）”；
argparse 不是“更高级”，而是把重复劳动标准化：它内置参数类型校验、自动处理 --help、统一错误格式（比如 error: argument count: invalid int value: 'abc'），还能通过 add_argument(..., nargs='?') 灵活支持可选参数。
- 哪怕只用两三个参数，只要含可选标志（如
--debug）或需要默认值，argparse就值得引入 - 别为了“省一个 import”硬扛复杂逻辑——调试参数问题的时间远大于写三行
argparse代码 -
argparse.ArgumentParser的exit_on_error=False（Python 3.9+）能让你捕获解析异常而不退出，适合嵌入式调用场景
捕获异常后 exit 的几个关键细节
很多人以为 try/except 里调用 sys.exit() 就万事大吉，但实际容易忽略三点：
- 在
finally或信号处理器里调用sys.exit()可能被忽略，确保它出现在主流程顶层 - 不要在异常处理块里再抛新异常（比如
raise ValueError("bad arg")），这会让调用者难以区分是参数错还是业务逻辑错 - 如果脚本被其他 Python 进程
subprocess.run()调用，务必检查返回码（result.returncode），而不是只看 stdout 是否有错误字样
最常被忽略的是：sys.exit() 抛的是 SystemExit 异常，它能被外层 try 捕获——如果你在测试中 mock 了 sys.exit，记得用 side_effect 模拟真实行为，否则测试会漏掉退出路径。
