环境变量在脚本中如何统一管理

最佳实践与高效策略

目录导读

1. 环境变量管理的重要性与常见痛点
2. 核心方案：集中配置文件与加载策略
3. 实战技巧：多环境（开发/测试/生产）分离
4. 安全防线：敏感信息加密与访问控制
5. 脚本化工具：自动化加载与异常处理
6. 常见问题解答（FAQ）
7. 总结与行动清单

环境变量管理的重要性与常见痛点

环境变量是脚本与系统交互的桥梁,但很多开发者在实际管理中陷入混乱，典型问题包括：

• 硬编码敏感信息（如数据库密码）到脚本中
• 多环境（本地/测试/生产）切换时频繁修改源码
• 变量散落在多个启动脚本、Dockerfile、CI配置中，维护成本高
• 团队成员对变量命名规则意见不一

统一管理的核心目标：一份配置，处处生效；一次加密，全程安全。

核心方案：集中配置文件与加载策略

1 推荐结构

project/
├── .env                  # 默认环境变量（不提交Git）
├── .env.example          # 示例模板（提交Git，不含真实值）
├── .env.production       # 生产环境变量
├── .env.test             # 测试环境变量
├── config/
│   └── loader.sh         # 统一的加载脚本
└── scripts/
    ├── deploy.sh
    └── backup.sh

2 Bash脚本统一加载示例（config/loader.sh）

#!/bin/bash
# 加载指定环境文件，优先级：函数参数 > 环境变量APP_ENV > 默认
ENV_FILE=".env"
if [ -n "$1" ]; then
    ENV_FILE=".env.$1"
elif [ -n "$APP_ENV" ]; then
    ENV_FILE=".env.$APP_ENV"
fi
if [ ! -f "$ENV_FILE" ]; then
    echo "[ERROR] 环境文件 $ENV_FILE 不存在"
    exit 1
fi
# 逐行读取，忽略注释和空行，跳过已存在的变量（保护手动覆盖）
while IFS='=' read -r key value; do
    if [ -z "$key" ] || [[ $key == \#* ]]; then
        continue
    fi
    # 去除两侧空格和引号
    key=$(echo "$key" | xargs)
    value=$(echo "$value" | xargs | sed 's/^"//;s/"$//')
    if [ -z "${!key}" ]; then
        export "$key=$value"
    fi
done < "$ENV_FILE"
echo "[INFO] 已加载环境文件: $ENV_FILE"

3 其他脚本的调用方式

# deploy.sh 开头
source ./config/loader.sh production   # 指定为生产环境
# 之后直接使用 $DB_HOST, $API_KEY 等变量

实战技巧：多环境（开发/测试/生产）分离

1 配置文件命名与隔离

• 开发环境：.env.development（包含本地数据库、调试日志）
• 测试环境：.env.test（指向测试服务器、模拟外部API）
• 生产环境：.env.production（使用生产密钥、高安全等级）

2 通过环境变量激活配置

# 在CI/CD或Docker启动时设置
export APP_ENV=production
source ./config/loader.sh   # 自动读取.env.production

3 禁止提交真实文件到Git

在.gitignore中加入：

.env
.env.*.local
*.key
credentials.json

安全防线：敏感信息加密与访问控制

1 使用加密存储（推荐方案）

• 工具：sops（Mozilla出品）、vault（HashiCorp）、openssl
• 示例：sops -e -i .env.production（加密后无法直接阅读）
• 仅由CI/CD或运维人员持有解密密钥

2 避免在日志中暴露变量

# 脚本内慎用echo打印变量，以下操作危险：
# echo "连接数据库: $DB_PASSWORD"   # 禁止！
# 安全做法：仅打印占位符
echo "数据库连接已初始化（秘密不显示）"

3 最小权限原则

• 生产数据库密码应独立于测试库密码
• 密钥轮换机制：每90天更新一次，脚本自动检测新版本

脚本化工具：自动化加载与异常处理

1 构建统一入口函数

# 封装一个加载函数到公共库（common.sh）
function load_env() {
    local env="${1:-${APP_ENV:-development}}"
    local file=".env.$env"
    if load_env_file "$file"; then
        export APP_ENV="$env"
        return 0
    else
        echo "[FATAL] 无法加载环境: $env"
        exit 2
    fi
}

2 验证关键变量是否存在

# 在每个主脚本开头添加校验
source common.sh
load_env production
required_vars=("DB_HOST" "DB_PORT" "API_KEY")
for var in "${required_vars[@]}"; do
    if [ -z "${!var}" ]; then
        echo "[ERROR] 必需变量 $var 未设置"
        exit 1
    fi
done

3 Docker容器中的自动注入

# Dockerfile
COPY .env* /app/
RUN echo "source /app/config/loader.sh" >> /root/.bashrc
# 或通过docker-compose的env_file指定

常见问题解答（FAQ）

Q1：使用.env文件与操作系统的/etc/environment有何区别？ A1：.env文件是项目级配置，仅影响当前脚本执行上下文，不会污染全局环境，而/etc/environment影响整个系统，适合系统级常量（如PATH），但容易造成冲突且难以迁移。

Q2：多个团队成员共用同一.env文件，如何避免覆盖？ A2：推荐两种方案：

• 每人使用.env.local文件（被git忽略），主.env仅存放通用非敏感变量
• 使用环境变量优先级：脚本中允许手动设置变量，通过${!key}检查避免覆盖

Q3：敏感信息如何在CI/CD中安全传递？ A3：

• CI平台（如GitHub Actions、GitLab CI）内置Secret管理
• 在CI脚本中：echo "$DB_PASSWORD" | sops -e ...
• 不要将解密后的密钥写入构建日志

Q4：env文件编码不一致导致乱码？ A4：统一要求使用UTF-8 without BOM，并在脚本开头添加：

export LC_ALL=C.UTF-8

总结与行动清单

核心原则

1. 只维护一份配置文件模板（.env.example）
2. 按照环境分离（.env.development, .env.test, .env.production）
3. 敏感信息加密存储（sops/vault/openssl）
4. 脚本内统一加载（source config/loader.sh）

立即行动清单

• [ ] 删除脚本中的硬编码密码
• [ ] 创建.env.example并提交到Git
• [ ] 添加.env*到.gitignore
• [ ] 实现统一的loader.sh加载函数
• [ ] 为每个环境创建对应的.env文件
• [ ] 在CI/CD中集成加密密钥的自动解密

通过以上方法,你的脚本将从“野路子配置”进化为“企业级环境变量管理体系”——不仅减少错误，还能让团队协作更高效，同时满足安全审计要求。统一的是规则，灵活的是环境，安全的是秘密。