部署脚本中环境变量设置的实用技巧（实战经验分享）

在日常运维或开发工作中，写部署脚本是再常见不过的事。但很多人一上来就写执行命令，忽略了环境变量的合理设置，结果上线后发现配置不对，数据库连不上，API 地址还是测试环境的。其实，只要在脚本里把环境变量安排明白，很多问题都能提前避免。

为什么要在部署脚本里设环境变量？

举个例子：你写的程序在本地用的是本地数据库，在服务器上却要连生产库。如果代码里写死地址，每次换环境就得改代码，太麻烦。而通过环境变量，脚本运行时自动注入对应配置，一套代码走天下。

常见的设置方式

Linux 下最常见的部署脚本是 Shell 脚本。可以在脚本开头统一定义环境变量：

#!/bin/bash

export DB_HOST="prod-db.example.com"
export DB_PORT=5432
export API_BASE_URL="https://api.example.com"
export NODE_ENV="production"

# 启动服务
node app.js

这样启动 Node.js 服务时，程序就能通过 process.env.DB_HOST 拿到值。其他语言如 Python、Go 也都有读取环境变量的机制，原理一样。

不同环境怎么切换？

项目通常有开发、测试、预发布、生产等多个环境。可以为每个环境写一个独立的脚本，比如 deploy-prod.sh 和 deploy-staging.sh，各自设置不同的变量。

也可以用参数传入环境名，脚本内部判断：

#!/bin/bash

ENV=$1

if [ "$ENV" = "prod" ]; then
    export DB_HOST="prod-db.example.com"
    export LOG_LEVEL="error"
elif [ "$ENV" = "staging" ]; then
    export DB_HOST="staging-db.example.com"
    export LOG_LEVEL="debug"
else
    echo "Usage: $0 [prod|staging]"
    exit 1
fi

npm run start

敏感信息别硬编码

密码、密钥这类东西绝不能直接写在脚本里，尤其是要提交到 Git 的场景。可以先把敏感变量从脚本中移除，运行前由 CI/CD 系统注入，或者从安全存储（如 Hashicorp Vault、AWS Secrets Manager）动态获取。

如果实在要本地测试，可以用一个不提交的 .env.local 文件，脚本启动时加载：

if [ -f .env.local ]; then
    export $(cat .env.local | xargs)
fi

这样既方便调试，又不会误传密钥。

小细节：变量作用域

注意 export 的使用。只赋值不加 export，变量只在当前脚本生效，子进程拿不到。比如 node app.js 就读不到未导出的变量。所以关键配置一定要用 export 声明。

另外，变量命名建议统一风格，比如全大写加下划线，避免和系统变量冲突。像 MYAPP_DB_HOST 就比 dbhost 更清晰也更安全。

部署脚本看似简单，但把环境变量理顺了，能省下不少半夜救火的时间。别贪快图省事，该设的变量一个别漏，上线才安心。