直接用 sys.argv 解析布尔参数危险：所有参数默认为字符串，"False"等不会自动转为False；应区分“标志是否存在”和“标志是否为真”，推荐统一用存在即真模式，避免对字符串直接调用bool()。
直接用 sys.argv 解析布尔值参数是危险的——所有命令行参数默认都是字符串，"False"、"0"、空字符串甚至 "--flag=False" 都不会自动转成 False；硬写 if arg == "True" 会漏掉常见变体，也容易和 flag 存在性混淆。
区分“标志是否存在”和“标志是否为真”
命令行中布尔参数通常有两种语义：
-
存在即真：如
python script.py --verbose，只要写了--verbose就启用，不带值； -
显式赋值：如
python script.py --debug=True或--debug false，需解析右侧值。
混用这两种模式会导致逻辑混乱。推荐统一用第一种（argparse 默认行为），若必须支持显式赋值，应明确约定格式（如只接受 yes/no、true/false，不区分大小写）。
手动解析时避免 str 误判 bool()
bool("False") 是 True，bool("") 是 False，但空字符串未必代表用户想关掉功能——它可能只是参数没传。不要对原始字符串直接调 bool()。
立即学习“Python免费学习笔记（深入）”；
librosa 是一个用于音频和音乐分析的 Python 库。它提供了特征提取、频谱分析、节拍跟踪、起始检测和音频可视化的工具，基于 NumPy 和 SciPy 构建，用于科学音频计算。
- 检查参数是否存在：
"--debug" in sys.argv或遍历sys.argv[1:]找匹配项； - 若需取值，定位到
--debug后一位：idx = sys.argv.index("--debug") + 1，再校验idx ； - 值标准化：用
val.lower() in ("true", "t", "1", "yes", "y")判定为真，in ("false", "f", "0", "no", "n")判定为假，其他情况报错或忽略。
为什么不用 argparse 是自找麻烦
argparse 内置 action="store_true" / "store_false" 完美处理存在性布尔；用 type=lambda x: x.lower() in ("true", "yes", "1") 也能安全处理显式值。而手写 sys.argv 解析：
- 要自己处理短选项（
-v）、长选项（--verbose）、等号分隔（--debug=true）、空格分隔（--debug true）； - 无法自动生成 help 文本，出错时不提示用法；
- 多个布尔参数叠加时（
--dry-run --force），索引易越界或错位。
哪怕项目禁止第三方依赖，argparse 是 Python 标准库，零额外成本。
一个最小可行的手动解析片段（仅限必须不用 argparse 的场景）
以下代码只处理形如 python script.py --debug true --verbose 的情况：
import sys
<p>def parse_bool_arg(args, flag, default=False):
if flag not in args:
return default
idx = args.index(flag)
if idx + 1 >= len(args):
return True # 无值，默认开启
val = args[idx + 1]
if val.startswith('-'): # 下一个参数是另一个 flag，说明本 flag 无值
return True
return val.lower() in ('true', '1', 'yes', 'y')</p><p>debug_mode = parse_bool_arg(sys.argv, '--debug', default=False)
verbose = '--verbose' in sys.argv
注意：这个片段不处理 --debug=false 这种写法，也不校验重复 flag；真实项目里，这种边界情况越多，维护成本越高。
真正难的不是写几行 sys.argv 判断，而是定义清楚哪些字符串算“用户明确表达了否”，以及当用户输错时，程序该静默忽略、报错退出，还是 fallback 到默认值——这些决策比语法解析本身更重要。
