应使用 getopts 而非手动 shift 解析选项，因其支持参数校验、正确处理高位参数、提供明确错误提示；长选项需用 getopt 配合 getopts；调用时参数含空格必须加双引号。
直接用 getopts，别手写 while + shift 解析带参选项——它不处理长选项、不校验参数缺失、容易漏掉 ${10} 这类高位参数，出错时连报错位置都难定位。
为什么不用手动 shift 循环解析 -f file.txt
手动解析看似灵活，实则埋雷密集：
- 遇到
$10会误读成$1拼接字符0，必须写成${10}，但很多人根本意识不到 - 带参选项（如
-o output.log）需手动检查$2是否为空，否则脚本静默失败 - 选项和非选项参数混排时（如
./script.sh -v file1.txt -o out.log），shift逻辑极易错位，剩余参数位置错乱 - 没有统一错误提示机制，用户输错
-z或漏掉-f的值，脚本可能继续执行并产生诡异结果
getopts 解析 -a -b value -c 的标准写法
getopts 是 bash 内置命令，轻量、POSIX 兼容、错误反馈明确。关键点在 optstring 字符串和 OPTARG 的使用：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- optstring 中字母后加
:表示该选项必带参数，例如"a:b:c"→-a和-b需要值，-c是开关 - 首字符为
:（如":a:b:c"）可屏蔽默认错误输出，改由脚本自行处理（比如打印自定义 help） - 每次匹配成功，
opt变量存选项字母，OPTARG存其值（仅对带:的选项有效） - 循环结束后，用
shift $((OPTIND - 1))把已处理的选项从$@中剔除，剩下纯参数供后续使用
#!/bin/bash
while getopts ":a:b:c" opt; do
case $opt in
a) echo "A received: $OPTARG" ;;
b) echo "B received: $OPTARG" ;;
c) echo "C flag set" ;;
:) echo "Option -$OPTARG requires an argument." >&2; exit 1 ;;
\?) echo "Invalid option: -$OPTARG" >&2; exit 1 ;;
esac
done
shift $((OPTIND - 1))
echo "Remaining args: $*"
处理 --long-option 必须用 getopt（不是 getopts）
getopts 不支持长选项，硬要 hack 会破坏可维护性。此时应切到外部命令 getopt（注意没 s）：
- 先用
getopt -o ab:c --long action:,backup-dir:,clean -n script.sh -- "$@"标准化参数格式 - 用
eval set -- $(...)重载位置参数，把--action=start转成--action start这种getopts可识别的形式 - 再进一次
getopts循环，或直接用case $1 in --action) ... shift 2 ;;处理 - 注意：不同系统
getopt行为有差异（GNU vs BSD），生产环境建议加getopt --test前置检测
路径含空格、特殊字符时的参数安全传递
无论用哪种解析方式，调用脚本时若参数含空格或 * 等 shell 元字符，必须用双引号包裹，否则 shell 在传入脚本前就做了分词或 glob 展开：
- ✅ 正确：
./deploy.sh -c "/etc/my app/config.conf" -v "prod env" - ❌ 错误：
./deploy.sh -c /etc/my app/config.conf→ 脚本收到三个参数：-c、/etc/my、app/config.conf - ⚠️ 即使用了
getopts，如果调用方没引号，OPTARG拿到的也只是第一段，后面部分变成下一个$1，彻底错位
真正容易被忽略的是：这个责任不在脚本内，而在调用者——脚本无法“修复”已被 shell 分裂的参数。所有文档、help 提示里都得明确写上「路径请用双引号」，否则运维同事半夜改配置崩掉生产环境，你真解释不清。
