剥离硬编码环境变量的本质是将变量从脚本组成部分转为运行时输入契约：需定位深层硬编码（如拼接连接串、内联密码、写死路径）、按环境分离注入源（.env/dev、ci secrets、k8s secrets）、删除export并改用${var:-default}或校验退出，最后通过printenv、ps和健康接口三步验证。
直接剥离硬编码在脚本里的旧环境变量，不是“删掉几行 export 就完事”，而是要重建变量注入逻辑——让变量只在该出现的地方出现，且不随脚本一起打包、不混进 Git 历史、不跨环境泄漏。
先定位：哪些变量是真正在脚本里“硬编码”的
别被 export DB_HOST=localhost 这类显式语句蒙蔽。真正危险的是那些藏得深的：
- 脚本中拼接的连接串，比如
mysql -h $DB_HOST -P $DB_PORT -u root -p"123456"→ 密码"123456"是硬编码 - 用字符串插值写死的路径：
LOG_DIR="/opt/myapp/logs"，没走$APP_HOME/logs - 条件判断里写死的环境标识：
if [ "$ENV" = "prod" ]; then ... fi，而$ENV本身又来自export ENV=prod这一行 - 启动命令里内联的参数：
java -Dspring.profiles.active=dev -jar app.jar，把 profile 当配置项硬塞进去
这类内容一旦进容器镜像或部署包，就等于把环境契约焊死在二进制里。
再隔离：按环境维度拆解变量来源，切断脚本对变量的“自给自足”
目标是让脚本变成“纯执行器”，所有变量必须外部注入，且来源清晰可审计：
- 开发环境：用
.env文件 +docker-compose --env-file .env.dev up，配合python-dotenv或source 防止误加载 - 测试环境：CI 流水线中通过 secret 管理器（如 GitHub Actions secrets、GitLab CI variables）注入，禁止在
.gitlab-ci.yml里明文写DB_PASS: xxx - 生产环境：只允许通过 Kubernetes Secrets 挂载文件（如
/etc/secrets/db-password），或 systemd 的EnvironmentFile=/run/secrets/prod.env（权限 600，属主为服务用户）
关键动作：把原来脚本开头的 export XXX=yyy 全部删掉，改成 XXX=${XXX:-"default"} 或直接报错退出（如 [[ -z "$DB_HOST" ]] && echo "ERROR: DB_HOST missing" >&2 && exit 1）。
最后验证：迁移后确认变量不再从脚本泄露，且行为可预期
上线前跑三步检查：
- 进容器执行
printenv | grep -E '^(DB_|API_|LOG_|ENV_)'，确认只有你明确传入的变量存在，没有残留的DEV_MODE=true或OLD_CONFIG_PATH=/tmp/xxx - 查看进程启动命令：
ps aux | grep app.jar，确认-D参数、--config路径等全部来自环境变量或挂载配置，而非脚本内联字符串 - 在应用健康接口（如
/health/env）返回的摘要中，核对DB_HOST、STORAGE_ROOT等字段是否与当前环境一致，且敏感字段已脱敏（如显示***而非明文密码）
剥离的本质不是“删变量”，是把变量从脚本的“组成部分”变成运行时的“输入契约”。脚本越薄，迁移越稳。
