Linux 运维脚本的规范设计

脚本应使用 #!/bin/sh 并声明 utf-8 编码，优先采用 POSIX 兼容语法；参数解析用 getopts 或 getopt；操作前校验权限与存在性；日志输出到 stderr，退出码需语义明确；开头加 set -u 和引号包裹变量。

脚本开头必须声明解释器和编码

不写 #!/bin/bash 或写成 #!/usr/bin/env bash 看似小事，但会导致在不同环境（如容器、最小化系统）下直接执行失败。centos 7 默认无 /usr/bin/env 软链，而 Alpine 又默认没装 bash——用 #!/bin/sh 更稳妥，除非明确依赖 bash 特性（如数组、[[）。编码统一加 # -*- coding: utf-8 -*-，避免中文注释或日志在 cron 下乱码。

• 运维脚本尽量用 POSIX shell 兼容语法，减少 bash 扩展依赖
• 若必须用 bash，检查目标系统是否真有 /bin/bash，而非仅靠 env 查路径
• 避免在 shebang 中写绝对路径如 #!/usr/local/bin/bash，该路径在多数发行版不存在

参数解析必须用 getopts 或 while getopts

手写 if [ "$1" = "-f" ]; then 这类逻辑，无法处理短选项组合（如 -vf）、缺少参数报错、自动显示 usage，还容易被空格或特殊字符注入。用 getopts 是 POSIX 标准方案，轻量且可靠。

• getopts 不支持长选项（--force），如需长选项，改用 getopt（注意是外部命令，非内置，需判断是否存在）
• 务必在 getopts 循环后加 shift $((OPTIND-1))，否则剩余位置参数（如文件名）会错位
• 错误提示要输出到 &2，例如 echo "Error: -f requires argument" >&2，避免污染标准输出影响管道使用

关键操作前必须做权限与存在性校验

运维脚本常以 root 运行，但不是所有操作都需要 root 权限；盲目 sudo rm -rf /tmp/foo 或 chown -R nobody:nogroup /var/www，一旦路径拼错或变量为空，就是事故。每一步涉及文件系统、服务控制、网络配置的操作，都应先确认：目标是否存在、当前用户是否有权访问、操作是否可逆。

• 用 [ -d "$DIR" ] && [ -w "$DIR" ] 替代单纯 [ -d "$DIR" ]
• 修改系统配置前，先 cp "$CONF" "$CONF.bak-$(date +%s)"，并限制备份数量（避免填满磁盘）
• 重启服务前，用 systemctl is-active --quiet service-name 判断是否已运行，避免无谓 reload 失败
• 对传入的路径参数，用 realpath -m "$1" 归一化，防止相对路径、符号链接导致误操作

日志与退出码必须显式控制

运维脚本被 cron、ansible 或其他调度器调用时，只看 $? 和 stdout/stderr。默认不设退出码、不打日志，等于“静默失败”。比如一个检测磁盘空间的脚本，发现 /var 使用率超 90% 却只 echo 一句就 exit 0，监控系统永远收不到告警。

• 成功返回 0，预期失败（如服务未安装）返回 1，非预期错误（如权限拒绝、命令未找到）返回 2+，不要全用 0 或 1
• 日志统一走 logger -t "deploy.sh" "Starting backup"，比 echo 更易被 syslog 收集；若不用 syslog，至少重定向到文件并加时间戳：echo "$(date '+%F %T') INFO: backup done" >> /var/log/myscript.log
• 避免在函数里用 exit，改用 return + 外层判断，否则函数调用后整个脚本中断，无法做清理（trap 不生效）

实际部署中，最常被忽略的是「变量未引号包裹导致空格截断」和「未设 set -u 导致未定义变量静默为 NULL」。这两条加在脚本开头，能提前暴露 60% 以上的低级错误。