argparse.ArgumentParser() 初始化时通常无需传 prog，但封装为命令行工具时应显式指定以修正 help 中的程序名；布尔参数优先用 'store_true'，除非需三态；位置参数须置于可选参数之前；通过 type 和 default 配合 help 可显示类型与默认值。
argparse.ArgumentParser() 初始化时要不要传 prog？
默认情况下，argparse.ArgumentParser() 会自动从 sys.argv[0] 推断程序名，多数时候够用。但如果你的脚本被封装成命令行工具（比如通过 entry_points 注册为 mytool），而实际执行的是某个内部模块，help 里却显示 python -m mypackage.cli，就容易误导用户。
这时显式传入 prog='mytool' 能让帮助信息更准确：
parser = argparse.ArgumentParser(prog='mytool', description='A fast file processor')
注意：它只影响 help 输出和错误提示中的程序名，不影响参数解析逻辑。
add_argument() 的 action 值选 'store_true' 还是 'store_const'？
两者都用于布尔型开关，但行为不同：
立即学习“Python免费学习笔记（深入）”；
-
'store_true'：遇到该参数就设为True，没出现就是False（默认值） -
'store_const'：必须配合const=...使用，适合多开关共用一个变量，比如--verbose和--quiet都写进同一个verbosity字段
常见误用：想实现「有参数就开，没参数就关」却用了 store_const 却忘了给 const，结果参数存在时值仍是 None。
推荐优先用 store_true，除非你明确需要三态（如 0/1/2 日志级别）：
parser.add_argument('--debug', action='store_true', help='Enable debug logging')位置参数和可选参数混用时，为什么 parse_args() 报错说 “unrecognized arguments”？
典型原因是：位置参数写在了可选参数后面，而用户又漏写了某个必需的位置参数，导致后续看起来像参数的字符串被当成未知参数处理。
例如：
parser.add_argument('input_file')
parser.add_argument('--output', '-o')
# 用户运行：python script.py --output result.txt
# → 缺少 input_file，但 argparse 不会报 “missing required argument”，而是把 --output 当成位置参数、result.txt 当成下一个位置参数，最后发现 --output 已定义，却没匹配上，报 unrecognized解决方法：
- 把所有位置参数放在
add_argument()调用的最前面 - 对必需参数，显式加
required=True（仅对可选参数有效）或用nargs控制数量 - 调用
parse_args()前先检查len(sys.argv) ，提前提示用法
怎么让 --help 显示更清晰的类型提示和默认值？
默认 help 不显示类型和默认值，用户得看源码猜。加两个参数就能改善：
-
type=str或type=int：会在 help 里显示[type: str] -
default=...：配合help='... (default: %(default)s)'，自动填充默认值
注意：如果 default 是 None 或未设，默认值不会显示；空字符串 '' 会被正常渲染。
示例：
parser.add_argument('--port', type=int, default=8000,
help='Server port (default: %(default)s)')输出 help 时会显示：--port PORT Server port (default: 8000)
argparse 的坑往往不在语法，而在“默认行为”和“用户直觉”的错位——比如位置参数顺序、help 文本里的默认值是否可见、布尔参数没出现时的初始状态。这些细节不报错，但会让脚本在真实协作中反复被问“为什么我加了 --xxx 没生效”。
