getopts仅支持posix短选项（-a、-b value、-abc），不支持长选项（--help）和等号形式（-f=file）；要求选项前置，遇非-参数即停止解析；需用shift $((optind-1))处理剩余参数。
getopts 能处理哪些选项格式
getopts 只支持 POSIX 标准的短选项（-a、-b value、-abc 连写），不支持长选项（--help、--output=file.txt）。它也不区分选项顺序，但要求所有选项必须出现在非选项参数之前（即 ./script.sh -v -f file.txt 合法，./script.sh file.txt -v 中的 -v 会被忽略）。
常见错误现象：getopts 遇到第一个非 - 开头的参数就停止解析，后续的 -x 不再被识别；未声明需参数的选项后紧跟值（如 -fconfig.txt）会被当作一个整体，OPTARG 拿不到分离后的值。
- 选项字符串（如
":ab:f:h"）中，每个字母代表一个合法短选项 - 字母后加
:表示该选项必须带参数（getopts会自动从下一个词或同一词后缀提取） - 开头加
:表示启用“静默模式”：不打印默认错误信息，由脚本自行处理?和:的情况
如何正确声明并循环读取选项
核心是用 while getopts "ab:f:h" opt 配合 case 分支，每次迭代 opt 是当前解析出的选项字母，OPTARG 是其参数（仅对带 : 的选项有效）。
容易踩的坑：getopts 内部维护位置索引（OPTIND），循环结束后若需访问剩余非选项参数（如文件名列表），必须用 shift $((OPTIND-1)) 将参数列表向前移动，否则 $1 仍是第一个选项而非首个文件名。
示例片段：
while getopts ":ab:f:h" opt; do
case $opt in
a) flag_a=1 ;;
b) val_b="$OPTARG" ;;
f) file="$OPTARG" ;;
h) echo "Usage: $0 [-a] [-b val] [-f file]"; exit 0 ;;
:) echo "Option -$OPTARG requires an argument." >&2; exit 1 ;;
?) echo "Invalid option: -$OPTARG" >&2; exit 1 ;;
esac
done
shift $((OPTIND-1))
# 此时 $@ 是剩下的非选项参数
带参数选项的两种写法及区别
-f filename 和 -ffilename 都能被正确解析为 file="filename"，前提是 f: 在选项字符串中。但行为差异在于容错性：
-
-f filename：两个独立词，OPTARG=filename -
-ffilename：一个词，OPTARG=filename（getopts自动截掉前缀-f） -
-f后无任何内容（如-f单独出现或-f -a）→ 触发:分支（静默模式下）或报错（非静默）
注意：getopts 不允许 -f=filename 这种等号形式——它不是 bash 内置命令的特性，而是某些高级解析器（如 getopt 命令）才支持的扩展语法。
为什么不用 getopt（小写）命令替代 getopts
getopt（外部命令，非内置）支持长选项和重排参数（-- 分隔符后也能解析选项），但依赖 util-linux 版本，不同系统行为不一致（如旧版不支持 --longoptions）。而 getopts 是 POSIX 标准 shell 内置，只要 /bin/sh 兼容 POSIX 就能用，移植性极高。
性能上，getopts 是 shell 内置，无进程创建开销；getopt 每次调用都 fork 新进程，脚本启动慢、循环中频繁调用更明显。
真正复杂需求（如混合长短选项、可选参数、多值参数）应换用其他语言（Python/Go）或接受限制只用 getopts + 手动解析剩余参数——硬塞进 getopts 只会让逻辑缠绕且难维护。
