部署脚本传参方法详解 实用操作步骤与避坑指南

常见的部署脚本传参方式

在日常开发中，写完代码只是第一步，真正让程序跑起来还得靠部署。而部署脚本作为自动化流程的核心，如何灵活接收外部参数就成了关键。很多人一开始都是把配置写死在脚本里，改个端口或路径就得重新编辑文件，既麻烦又容易出错。

其实，只要掌握几种常用的传参方法，就能让脚本变得通用又灵活。

命令行直接传参（Positional Arguments）

最简单的方式就是通过命令行位置参数传递。比如你有个部署脚本 deploy.sh，想动态指定环境和版本号：

./deploy.sh production v1.2.0

在脚本内部可以通过 $1、$2 获取：

#!/bin/bash
ENV=$1
VERSION=$2
echo "部署到 $ENV 环境，版本：$VERSION"

这种方式适合参数少、顺序固定的情况，但一旦参数多了就容易混淆。

使用选项式传参（Flags with getopts）

更规范的做法是用 -e production 这样的选项格式。Shell 提供了 getopts 来解析参数：

#!/bin/bash

ENV="dev"
PORT=8080

while getopts e:p: flag
do
    case "${flag}" in
        e) ENV=${OPTARG} ;;
        p) PORT=${OPTARG} ;;
    esac
done

echo "环境：$ENV，端口：$PORT"

调用时可以这样：

./deploy.sh -e staging -p 9000

参数顺序不再重要，可读性也更强，适合中等复杂度的脚本。

环境变量传参

另一种常见方式是通过环境变量传参，特别适合 CI/CD 流水线场景。比如 Jenkins 或 GitHub Actions 中设置：

DEPLOY_ENV=production VERSION=v2.0.0 ./deploy.sh

脚本中直接使用 $DEPLOY_ENV 和 $VERSION 即可。这种方式无需修改脚本逻辑，换环境只需改变量，非常干净。

配置文件注入

当参数越来越多，比如数据库地址、密钥、超时时间等，写在命令行就不现实了。这时候可以把配置抽成一个文件，比如 config.env：

ENV=production
DB_HOST=db.prod.example.com
API_TIMEOUT=30

然后在脚本开头加载：

if [ -f config.env ]; then
    source config.env
fi

结合命令行参数优先级控制，可以实现“配置文件兜底，命令行覆盖”的策略。

混合使用更灵活

实际项目中往往不是非此即彼。比如先加载默认配置，再读环境变量，最后用命令行参数覆盖：

#!/bin/bash

# 默认值
ENV=${DEPLOY_ENV:-dev}
PORT=${PORT:-8080}

# 命令行可覆盖
while getopts e:p: flag
do
    case "${flag}" in
        e) ENV=${OPTARG} ;;
        p) PORT=${OPTARG} ;;
    esac
done

echo "最终部署配置：环境=$ENV，端口=$PORT"

这种层层覆盖的模式，在真实部署中非常实用。开发本地跑用默认值，测试环境走 CI 变量，上线前还能手动指定参数验证。

传参看似小事，但设计得好坏直接影响脚本的复用性和稳定性。别再把所有配置都写死在脚本里了，动动手指加几个参数，下次改配置时你会感谢自己。