1. 前言

1.1 规范目的

为统一Linux脚本开发标准，提升脚本的可读性、可维护性、可复用性和安全性，降低团队协作成本，避免因不规范开发导致的脚本异常、难以调试、权限泄露等问题，特制定本规范。本规范适用于所有基于Linux系统（CentOS、Ubuntu、Debian等）开发的Shell脚本（bash为主），包括系统运维脚本、应用部署脚本、数据处理脚本等，所有脚本开发、修改、维护人员必须严格遵守。

1.2 适用范围

• 本规范适用于公司内部所有Linux环境下的Shell脚本（bash版本优先遵循bash 4.0+标准）；

• 适用于脚本开发、测试、部署、维护的全生命周期；

• 适用于所有参与脚本开发、评审、使用的人员（开发工程师、运维工程师、测试工程师等）；

• 若脚本涉及特定业务场景（如数据库操作、容器管理），除遵循本规范外，还需遵循对应业务的专项规范。

1.3 核心原则

• 可读性优先：脚本代码需清晰易懂，命名、注释规范，便于他人快速理解逻辑和修改；

• 安全性至上：严格控制脚本权限、输入校验，避免权限泄露、命令注入、路径遍历等安全风险；

• 可维护性：脚本结构清晰、模块化设计，便于后续修改、扩展和问题排查；

• 兼容性：兼顾不同Linux发行版的差异，避免使用特定发行版独有的命令（若必须使用，需添加兼容处理）；

• 规范性：严格遵循本规范的所有要求，避免随意编写、无规则命名、无注释等情况。

2. 脚本基础规范

2.1 脚本文件格式

• 脚本文件后缀统一为 .sh，例如 backup_data.sh、deploy_app.sh，禁止使用无后缀或非 .sh 后缀（如 .bash、.script）；

• 脚本文件编码格式统一为 UTF-8，避免使用 GBK、GB2312 等编码，防止中文注释乱码；

• 脚本行结束符统一为 Linux 格式（LF），禁止使用 Windows 格式（CRLF），避免出现 ^M 异常字符（可通过 dos2unix 命令转换）；

• 脚本文件大小控制：单个脚本文件建议不超过 1000 行，若逻辑复杂，可拆分为多个子脚本，通过主脚本调用，提升可维护性。

2.2 脚本权限设置

• 脚本文件权限统一设置为 755（rwxr-xr-x），即所有者可读写执行，其他用户只读执行，禁止设置为 777（全权限），避免权限泄露；

• 脚本执行用户：优先使用普通用户执行脚本，禁止随意使用 root 用户执行（若必须使用 root，需在脚本头部添加警告注释，并在执行前进行权限校验）；

• 临时文件权限：脚本运行过程中生成的临时文件，权限设置为 600（rw-------），避免临时文件被其他用户读取或修改，脚本执行完毕后需及时删除临时文件。

2.3 脚本头部声明

所有脚本头部必须包含固定格式的声明信息，顺序不可颠倒，内容完整，便于他人快速了解脚本用途、作者、版本等信息，示例如下：

#!/bin/bash
##############################################################################
# 脚本名称：backup_data.sh
# 脚本用途：用于每日凌晨备份MySQL数据库数据，并将备份文件上传至远程服务器
# 作    者：张三
# 创 建 日：2026-04-01
# 版    本：v1.0
# 依赖环境：bash 4.0+、mysql 8.0+、rsync 3.0+
# 执行权限：需要root权限（用于读取MySQL配置文件）
# 注意事项：1. 需提前配置远程服务器rsync权限；2. 备份文件保留7天，自动清理过期文件
# 异常处理：备份失败时发送邮件通知管理员，邮件地址：admin@example.com
##############################################################################

• 首行必须为 #!/bin/bash，指定脚本解释器为 bash，禁止使用 #!/bin/sh（sh 与 bash 存在兼容性差异）；

• 声明信息需包含：脚本名称、脚本用途、作者、创建日期、版本、依赖环境、执行权限、注意事项、异常处理（可选，复杂脚本必须包含）；

• 版本号格式统一为vX.Y（X为主版本号，Y为次版本号），版本更新时，需同步更新版本号和更新说明（添加在注意事项或单独添加更新记录）；

• 若脚本依赖特定命令或工具，需明确列出依赖环境的版本要求，避免因环境差异导致脚本执行失败。

3. 命名规范

3.1 脚本文件命名

• 采用“功能描述+后缀.sh”的命名方式，全小写字母，单词之间用下划线 _ 分隔，禁止使用空格、特殊字符（如 !@#$%^&*()）、中文、大写字母；

• 命名需简洁明了，一眼能看出脚本用途，避免模糊命名（如 script.sh、test.sh）；

• 示例：正确命名 deploy_nginx.sh（部署Nginx脚本）、clean_log.sh（清理日志脚本）；错误命名 DeployNginx.sh、脚本.sh、test123.sh。

3.2 变量命名

• 变量命名采用全大写字母，单词之间用下划线 _ 分隔，符合Shell变量命名规则（只能以字母或下划线开头，不能包含空格和特殊字符）；

• 变量命名需具有语义性，明确变量的用途，避免使用无意义的变量名（如 a、b、var1）；

• 常量变量（固定不变的值，如路径、端口、阈值）需在脚本头部集中定义，便于统一修改；

• 临时变量（仅在局部使用，如循环变量）可采用小写字母+下划线，但需避免与系统变量、常量变量重名；

• 禁止使用系统环境变量的名称作为自定义变量（如 PATH、HOME、USER），若需修改系统变量，需在修改前备份原始值，执行完毕后恢复；

• 示例：正确命名 BACKUP_PATH=/data/backup（备份路径）、DB_PORT=3306（数据库端口）、MAX_LOG_SIZE=1024（日志最大大小）；错误命名 backupPath、var1=10、PATH=/usr/local/bin。

3.3 函数命名

• 函数命名采用全小写字母，单词之间用下划线 _ 分隔，命名需体现函数的功能；

• 函数名避免过长（建议不超过20个字符），避免使用系统命令名作为函数名（如 ls、cd、cp）；

• 若函数为脚本内部私有函数（不对外调用），可在函数名前加下划线 _ 区分；

• 示例：正确命名 backup_mysql()（备份MySQL函数）、send_mail()（发送邮件函数）、_check_dependency()（私有依赖检查函数）；错误命名 BackupMysql()、func1()、ls()。

3.4 其他命名

• 临时文件/目录命名：采用“脚本名_时间戳_随机数”的格式，避免临时文件重名，例如 backup_data_20260401_123456.tmp；

• 日志文件命名：采用“脚本名_日期.log”的格式，便于按日期查找日志，例如 deploy_app_20260401.log；

• 参数命名：脚本参数若有明确含义，可在脚本头部注释中说明每个参数的用途，例如 $1（数据库用户名）、$2（数据库密码）。

4. 编码规范

4.1 代码缩进

• 统一使用 4 个空格进行缩进，禁止使用 Tab 键缩进（不同编辑器对 Tab 的解析不同，易导致格式混乱）；

• 缩进场景：循环（for、while）、条件判断（if、case）、函数体、嵌套逻辑等，缩进需层次清晰，便于区分代码块；

• 示例：

# 正确缩进
if [ $? -eq 0 ]; then
    echo "备份成功"
    # 调用发送邮件函数
    send_mail "备份成功"
else
    echo "备份失败"
    send_mail "备份失败"
    exit 1
fi

4.2 空行规范

• 脚本头部声明与正文之间空 2 行；

• 不同功能模块之间空 1 行，例如变量定义模块、函数定义模块、主逻辑模块之间；

• 函数内部，不同逻辑块之间空 1 行；

• 禁止连续空 2 行及以上（除脚本头部声明与正文之间）；

• 禁止在代码行前后添加无意义的空行；

• 示例：

#!/bin/bash
##############################################################################
# 脚本名称：backup_data.sh
# 脚本用途：用于每日凌晨备份MySQL数据库数据，并将备份文件上传至远程服务器
# 作    者：张三
# 创 建 日：2026-04-01
# 版    本：v1.0
# 依赖环境：bash 4.0+、mysql 8.0+、rsync 3.0+
# 执行权限：需要root权限（用于读取MySQL配置文件）
# 注意事项：1. 需提前配置远程服务器rsync权限；2. 备份文件保留7天，自动清理过期文件
##############################################################################


# 常量变量定义
BACKUP_PATH=/data/backup
DB_HOST=localhost
DB_USER=root
DB_PASS=123456
REMOTE_HOST=192.168.1.100
REMOTE_PATH=/backup/data


# 函数定义：发送邮件通知
send_mail() {
    local subject=$1
    local content=$2
    echo "$content" | mail -s "$subject" admin@example.com
}


# 函数定义：备份MySQL数据库
backup_mysql() {
    # 创建备份目录（若不存在）
    if [ ! -d "$BACKUP_PATH" ]; then
        mkdir -p "$BACKUP_PATH"
    fi
    
    # 备份数据库
    mysqldump -h"$DB_HOST" -u"$DB_USER" -p"$DB_PASS" --all-databases > "$BACKUP_PATH/mysql_backup_$(date +%Y%m%d).sql"
    
    # 检查备份是否成功
    if [ $? -eq 0 ]; then
        echo "$(date +%Y-%m-%d %H:%M:%S) MySQL备份成功"
        return 0
    else
        echo "$(date +%Y-%m-%d %H:%M:%S) MySQL备份失败"
        return 1
    fi
}


# 主逻辑
echo "开始执行备份任务：$(date +%Y-%m-%d %H:%M:%S)"
backup_mysql
if [ $? -eq 0 ]; then
    # 上传备份文件至远程服务器
    rsync -avz "$BACKUP_PATH/" "$REMOTE_HOST:$REMOTE_PATH"
    if [ $? -eq 0 ]; then
        echo "备份文件上传成功"
        send_mail "MySQL备份成功" "备份文件已上传至远程服务器，路径：$REMOTE_PATH"
    else
        echo "备份文件上传失败"
        send_mail "MySQL备份警告" "备份成功，但文件上传失败"
    fi
else
    send_mail "MySQL备份失败" "备份过程中出现异常，请及时排查"
    exit 1
fi

echo "备份任务执行完毕：$(date +%Y-%m-%d %H:%M:%S)"

4.3 命令规范

• 命令使用：优先使用标准命令，避免使用特定Linux发行版独有的命令（如 CentOS 的 yum、Ubuntu 的 apt，若必须使用，需添加发行版判断逻辑）；

• 命令参数：命令参数统一使用长格式（若支持），提高可读性，例如 ls --long 优于 ls -l，cp --recursive 优于 cp -r；

• 路径使用：所有路径均使用绝对路径，禁止使用相对路径（避免因脚本执行目录变化导致路径错误），例如/usr/local/nginx/sbin/nginx 优于 ./nginx；

• 管道与重定向：

  • 管道 | 前后各加 1 个空格，例如ls --long /data | grep .log，禁止 ls --long /data|grep .log；

  • 重定向符号 >、>>、< 前后各加 1 个空格，例如 echo "test" > /tmp/test.log，禁止 echo "test">/tmp/test.log；

  • 禁止使用 >/dev/null 2>&1 屏蔽所有输出（除非明确不需要任何输出），若需屏蔽错误输出，需说明原因，并保留正常输出；

• 循环与条件判断：

  • if 条件判断：[ 后、] 前各加 1 个空格，条件表达式中的运算符前后各加 1 个空格，例如 if [ $count -gt 10 ]; then，禁止 if [$count -gt10];then；

  • for 循环：循环变量与 in、do 之间各加 1 个空格，例如 for file in $(ls $BACKUP_PATH); do；

  • case 语句：case 后加空格，in 另起一行，每个分支的 ;; 位于行尾，例如：

case $status in
    0)
        echo "执行成功"
        ;;
    1)
        echo "执行失败"
        ;;
    *)
        echo "状态异常"
        ;;
esac

• 禁止在一行内写多个命令（用 ; 分隔），除非命令非常简单且逻辑相关，例如 mkdir -p /data/backup; cd /data/backup，复杂命令需分行编写；

• 命令换行：若命令过长（超过80个字符），需换行编写，换行符 \ 放在命令末尾，且 \ 前加 1 个空格，换行后缩进 4 个空格，例如：

mysqldump -h"$DB_HOST" -u"$DB_USER" -p"$DB_PASS" \
    --all-databases \
    --single-transaction \
    --quick \
    > "$BACKUP_PATH/mysql_backup_$(date +%Y%m%d).sql"

4.4 变量使用规范

• 变量赋值：赋值符号 = 前后无空格，例如 BACKUP_PATH=/data/backup，禁止 BACKUP_PATH = /data/backup；

• 变量引用：所有变量引用时，均使用 ${变量名} 格式，禁止直接使用 $变量名（避免变量名与后续字符混淆），例如 ${BACKUP_PATH}/mysql_backup.sql，禁止 $BACKUP_PATH/mysql_backup.sql；

• 变量初始化：所有变量在使用前必须初始化，避免使用未定义的变量（可在脚本头部添加set -u，强制检查未定义变量，避免脚本异常）；

• 局部变量：函数内部使用的变量，需用 local 声明为局部变量，避免污染全局变量，例如 local subject=$1；

• 变量类型：Shell 变量默认为字符串类型，若需进行数值运算，需使用 (( )) 或 expr，例如count=$((count + 1))，禁止直接使用 count=count+1。

4.5 函数使用规范

• 函数定义：函数需在脚本头部集中定义（变量定义之后，主逻辑之前），便于查找和维护；

• 函数参数：函数参数通过 $1、$2... 接收，参数个数需在函数头部注释中说明，例如：

# 函数用途：发送邮件通知
# 参数1：邮件主题
# 参数2：邮件内容
send_mail() {
    local subject=$1
    local content=$2
    echo "$content" | mail -s "$subject" admin@example.com
}

• 函数返回值：函数通过 return 返回状态码（0 表示成功，非 0 表示失败），禁止使用 echo 返回值（避免与正常输出混淆）；

• 函数调用：函数调用时，参数之间用空格分隔，若参数包含空格，需用双引号包裹，例如 send_mail "备份成功" "2026-04-01 备份任务执行完成"；

• 函数复用：相同逻辑的代码需封装为函数，避免重复编写，例如多个地方需要发送邮件，可封装 send_mail() 函数，统一调用；

• 禁止函数嵌套：避免在函数内部定义另一个函数，导致代码逻辑混乱，可将嵌套逻辑拆分为多个独立函数。

4.6 错误处理规范

• 脚本开头添加 set -e（可选）：当脚本中任何命令执行失败（返回非 0 状态码）时，脚本立即退出，避免错误继续传播；若需忽略特定命令的错误，可在命令后加 || true，例如 rm -f /tmp/test.log || true；

• 命令执行检查：关键命令（如备份、部署、文件传输）执行后，必须检查执行状态（$?），根据状态执行后续逻辑（成功提示、失败告警、退出脚本）；

• 异常提示：错误信息需清晰、具体，说明错误原因、错误位置，便于排查，禁止使用模糊提示（如执行失败），示例：echo "ERROR: MySQL备份失败，原因：无法连接数据库（主机：$DB_HOST，端口：$DB_PORT）"；

• 退出状态码：脚本退出时，需返回明确的状态码，0 表示成功，非 0 表示失败，不同错误类型使用不同的状态码（例如 1：参数错误，2：依赖缺失，3：执行失败），示例：

# 检查参数个数
if [ $# -ne 2 ]; then
    echo "ERROR: 参数错误，需传入2个参数（数据库用户名、密码）"
    exit 1
fi

# 检查依赖命令
if ! command -v mysqldump &> /dev/null; then
    echo "ERROR: 依赖缺失，未找到mysqldump命令，请安装MySQL客户端"
    exit 2
fi

• 告警机制：脚本执行失败时，需通过邮件、短信等方式通知管理员（复杂脚本必须包含），简单脚本可输出错误信息至日志；

• 清理机制：脚本执行过程中若出现异常，需清理临时文件、恢复环境（如关闭启动的服务、恢复修改的配置），避免残留垃圾数据。

5. 注释规范

5.1 注释原则

• 注释需简洁、准确、有用，避免无意义的注释（如 # 这里是注释、# 执行命令）；

• 注释与代码同步更新：代码修改时，对应的注释必须同步修改，避免注释与代码不一致；

• 注释语言：统一使用中文注释，禁止使用英文注释（除非脚本面向国外人员）；

• 注释位置：注释需放在被注释内容的上方或右侧，避免放在代码中间，影响可读性；

• 禁止过度注释：简单易懂的代码（如mkdir -p $BACKUP_PATH）无需注释，复杂逻辑、特殊处理、关键命令必须添加注释。

5.2 注释类型及格式

5.2.1 头部注释

脚本头部注释需遵循本规范 2.3 节的要求，完整包含脚本相关信息，格式统一，使用 # 开头，每行一个注释项，示例见 2.3 节。

5.2.2 模块注释

脚本中不同功能模块（变量定义、函数定义、主逻辑）的上方，需添加模块注释，说明模块的功能，格式为 # 模块名称：模块功能描述，示例：

# 常量变量定义：定义脚本所需的所有常量，便于统一修改
BACKUP_PATH=/data/backup
DB_HOST=localhost

# 函数定义：封装脚本所需的工具函数，提高复用性
send_mail() {
    # 函数内部逻辑
}

5.2.3 函数注释

每个函数定义的上方，需添加函数注释，说明函数的用途、参数、返回值，格式统一，示例：

# 函数用途：备份MySQL数据库，生成备份文件并保存至指定目录
# 参数1：无（依赖全局变量DB_HOST、DB_USER、DB_PASS、BACKUP_PATH）
# 返回值：0（备份成功）、1（备份失败）
backup_mysql() {
    # 函数内部逻辑
}

5.2.4 行内注释

针对复杂逻辑、特殊处理、关键命令，需在代码行右侧添加行内注释，说明代码的作用、原因，注释与代码之间用 2 个空格分隔，示例：

# 备份数据库，使用--single-transaction保证备份一致性（适用于InnoDB引擎）
mysqldump -h"$DB_HOST" -u"$DB_USER" -p"$DB_PASS" --single-transaction > "$BACKUP_PATH/backup.sql"

# 清理7天前的备份文件，避免磁盘空间不足
find "$BACKUP_PATH" -name "mysql_backup_*.sql" -mtime +7 -delete

5.2.5 临时注释

用于临时注释掉代码（如调试、测试），需在注释前添加 # TODO，说明注释原因和恢复时间，避免遗忘恢复，示例：

# TODO：临时注释，调试时跳过文件上传步骤，2026-04-05恢复
# rsync -avz "$BACKUP_PATH/" "$REMOTE_HOST:$REMOTE_PATH"

6. 安全规范

6.1 权限安全

• 禁止使用 chmod 777 赋予文件/目录全权限，最小权限原则：仅授予必要的权限；

• 脚本执行用户：优先使用普通用户，若必须使用 root，需在脚本中添加用户校验，确认当前用户为 root，示例：

if [ "$(whoami)" != "root" ]; then
    echo "ERROR: 该脚本需使用root用户执行，请切换用户后重试"
    exit 1
fi

• 敏感信息保护：脚本中禁止硬编码敏感信息（如密码、密钥、token），需通过环境变量、配置文件（权限 600）、命令行参数传入，示例：

# 错误方式：硬编码密码
DB_PASS=123456

# 正确方式1：通过环境变量传入
DB_PASS=$DB_PASSWORD

# 正确方式2：通过配置文件读取（配置文件权限600）
source /etc/backup.conf  # 配置文件中包含DB_PASS=123456

• 禁止在脚本中使用sudo 执行命令（除非必要），若必须使用，需确保 sudo 无需输入密码（通过配置 /etc/sudoers），避免脚本执行时卡住。

6.2 输入安全

• 参数校验：脚本接收命令行参数时，需校验参数个数、参数格式，避免非法参数导致脚本异常或安全风险（如命令注入），示例：

# 校验参数个数
if [ $# -ne 1 ]; then
    echo "ERROR: 需传入1个参数（备份日期，格式：YYYYMMDD）"
    exit 1
fi

# 校验参数格式（YYYYMMDD）
if ! echo "$1" | grep -qE '^[0-9]{8}$'; then
    echo "ERROR: 参数格式错误，需为YYYYMMDD格式（如20260401）"
    exit 1
fi

• 禁止直接使用用户输入的参数作为命令执行（避免命令注入），若需使用，需进行转义处理，示例：

# 错误方式：直接使用用户输入，存在命令注入风险
user_input=$1
ls $user_input  # 若user_input为"; rm -rf /"，会执行删除命令

# 正确方式：转义处理
user_input=$1
ls "$user_input"  # 用双引号包裹，避免命令注入

• 文件路径校验：若脚本接收文件/目录路径作为参数，需校验路径是否存在、是否为合法路径，避免路径遍历攻击，示例：

file_path=$1
# 校验路径是否存在
if [ ! -f "$file_path" ]; then
    echo "ERROR: 文件不存在：$file_path"
    exit 1
fi
# 校验路径是否为绝对路径（避免相对路径遍历）
if [ "${file_path:0:1}" != "/" ]; then
    echo "ERROR: 请传入绝对路径：$file_path"
    exit 1
fi

6.3 命令安全

• 禁止使用 rm -rf *、rm -rf / 等危险命令，若必须使用 rm -rf，需添加校验逻辑，确认删除的路径正确，示例：

delete_path=/data/backup/old
# 校验删除路径，避免误删
if [ "$delete_path" = "/" ] || [ "$delete_path" = "/data" ]; then
    echo "ERROR: 禁止删除危险路径：$delete_path"
    exit 1
fi
# 确认删除（可选，适用于重要操作）
read -p "确认删除 $delete_path 下的所有文件？(y/n) " confirm
if [ "$confirm" != "y" ]; then
    echo "取消删除操作"
    exit 0
fi
rm -rf "$delete_path"/*

• 禁止使用 eval、exec 等执行动态命令（除非必要），若必须使用，需严格校验命令内容，避免恶意命令执行；

• 使用 grep、sed、awk 等命令处理文本时，需注意特殊字符转义，避免命令执行异常。

7. 调试与日志规范

7.1 调试规范

• 脚本调试时，可在开头添加 set -x（开启调试模式，输出所有执行的命令及参数），调试完成后需删除或注释该语句；

• 复杂脚本可添加调试参数（如 -d），通过参数控制是否开启调试模式，示例：

# 调试模式控制
if [ "$1" = "-d" ]; then
    set -x
    shift  # 移除调试参数，避免影响后续参数处理
fi

• 调试过程中，可添加临时的 echo 语句，输出变量值、命令执行状态，便于排查问题，调试完成后需删除临时 echo 语句；

• 禁止将调试信息保留在生产环境的脚本中，避免泄露敏感信息。

7.2 日志规范

• 所有脚本必须输出日志，日志需包含时间戳、日志级别（INFO、ERROR、WARN）、日志内容，便于问题排查；

• 日志文件路径统一为 /var/log/脚本名/，日志文件命名为 脚本名_日期.log，例如 /var/log/backup_data/backup_data_20260401.log；

• 日志输出方式：脚本执行过程中，将日志同时输出到控制台和日志文件，示例：

# 定义日志路径和文件名
LOG_DIR=/var/log/backup_data
LOG_FILE="$LOG_DIR/backup_data_$(date +%Y%m%d).log"

# 创建日志目录（若不存在）
if [ ! -d "$LOG_DIR" ]; then
    mkdir -p "$LOG_DIR"
    chmod 755 "$LOG_DIR"
fi

# 日志输出函数（同时输出到控制台和日志文件）
log() {
    local level=$1
    local content=$2
    local time=$(date +%Y-%m-%d %H:%M:%S)
    echo "[$time] [$level] $content" | tee -a "$LOG_FILE"
}

# 日志使用示例
log "INFO" "开始执行备份任务"
log "ERROR" "MySQL备份失败，无法连接数据库"
log "WARN" "备份文件大小超过10GB，请注意磁盘空间"

• 日志级别规范：

  • INFO：正常执行的信息（如脚本启动、任务开始、执行成功）；

  • WARN：警告信息（如备份文件过大、磁盘空间不足，但不影响脚本执行）；

  • ERROR：错误信息（如备份失败、命令执行异常，影响脚本执行）；

• 日志清理：日志文件保留7-30天，可在脚本中添加日志清理逻辑，定期删除过期日志，避免磁盘空间不足；

• 禁止在日志中输出敏感信息（如密码、密钥），若必须输出，需进行脱敏处理（如只输出密码的前2位）。

8. 兼容性与可移植性规范

• 发行版兼容：脚本需兼顾主流Linux发行版（CentOS 7+/Ubuntu 18.04+/Debian 10+），若使用发行版独有的命令，需添加发行版判断逻辑，示例：

# 判断Linux发行版，安装依赖
if [ -f /etc/redhat-release ]; then
    # CentOS/RHEL系列
    yum install -y mysql-client rsync
elif [ -f /etc/lsb-release ]; then
    # Ubuntu系列
    apt update && apt install -y mysql-client rsync
elif [ -f /etc/debian_version ]; then
    # Debian系列
    apt update && apt install -y mysql-client rsync
else
    echo "ERROR: 不支持当前Linux发行版，请手动安装依赖"
    exit 1
fi

• bash版本兼容：脚本需兼容bash 4.0+版本，禁止使用bash 4.0以上独有的特性（如关联数组），若必须使用，需添加bash版本校验；

• 路径兼容：禁止使用用户家目录的相对路径（如 ~/.bashrc），统一使用绝对路径（如 /root/.bashrc）；

• 命令路径兼容：若脚本中使用的命令可能不在系统默认PATH中，需使用绝对路径调用命令，例如 /usr/bin/mysqldump 优于 mysqldump。

9. 脚本评审与维护规范

9.1 脚本评审

• 脚本开发完成后，必须经过至少1名同事评审，评审通过后方可部署使用；

• 评审内容：是否遵循本规范、代码可读性、安全性、逻辑正确性、错误处理完整性、兼容性；

• 评审记录：评审过程中发现的问题需记录，开发人员需及时修改，修改完成后重新评审，直至通过。

9.2 脚本维护

• 脚本部署后，需建立维护文档，记录脚本的部署路径、执行频率、依赖环境、异常处理方式；

• 脚本更新：当业务需求变化、环境变化或发现脚本漏洞时，需及时更新脚本，更新后需同步更新版本号、更新说明和维护文档；

• 脚本归档：废弃的脚本需归档保存（保留至少6个月），归档时需标注废弃原因和废弃日期，禁止直接删除；

• 定期检查：每月定期检查脚本执行情况，查看日志，排查异常，确保脚本正常运行。

10. 违规处理

• 若脚本未遵循本规范，评审不通过，需限期修改，直至符合规范；

• 因未遵循本规范导致脚本异常、数据丢失、安全漏洞等问题，由脚本开发人员承担相应责任；

• 定期开展脚本规范培训和检查，对规范执行较好的人员进行表彰，对多次违规的人员进行提醒和考核。

11. 附则

• 本规范自发布之日起生效，所有现有脚本需在3个月内完成整改，符合本规范要求；

• 本规范由公司运维部门负责解释和修订，根据业务发展和技术升级，可定期更新本规范；

• 若本规范与业务专项规范冲突，以业务专项规范为准；若本规范未覆盖的场景，需由开发人员和评审人员共同协商确定规范。