推荐用 sed 在构建流水线中直接替换配置文件占位符，如 sed -i "s/@VERSION@/${IMAGE_TAG}/g" app.conf，需确保 CI 环境为 Linux、变量已定义、占位符存在且无正则冲突。
直接在构建阶段用 sed 或 envsubst 替换配置文件中的占位符，是最轻量、最可控的方式；硬编码版本号或靠运行时注入环境变量再启动容器去改配置，容易错位、延迟、不可审计。
怎么用 sed 在流水线里原地替换配置文件里的版本占位符
前提是配置文件（如 app.conf、values.yaml、application.properties）中已预留明确占位符，例如 @VERSION@ 或 ${APP_VERSION}。CI 环境中必须确保 sed -i 可用，且路径权限正常。
- 推荐写法：
sed -i "s/@VERSION@/${IMAGE_TAG}/g" app.conf，其中${IMAGE_TAG}是流水线中已定义的变量（如$CI_COMMIT_TAG、$BUILD_ID或 Jenkins 的${env.VERSION_PREFIX}） - 注意 macOS 和 Linux 的
sed -i行为不一致：macOS 要求带备份后缀（sed -i '.bak' ...），Linux 不需要；CI 环境基本都是 Linux，可放心用-i直改 - 如果占位符含正则元字符（如
.、/、$），建议换分隔符，比如用#：sed -i "s#@VERSION@#${IMAGE_TAG}#g" - 替换前最好加校验：
grep -q '@VERSION@' app.conf || { echo "missing placeholder"; exit 1; }
为什么不用 envsubst 而要慎用它
envsubst 更适合处理形如 ${APP_VERSION} 这类 shell 风格变量，但它依赖环境变量存在且未被 shell 解析过——一旦你在 echo "version=${APP_VERSION}" > config 这类语句里提前展开，envsubst 就没得替了。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 正确用法：配置文件保留原始
${APP_VERSION}，执行前确保该变量已导出：export APP_VERSION=${IMAGE_TAG} && envsubst app.conf - 常见坑：Jenkins Pipeline 中
sh 'envsubst 不会继承上一步 <code>withEnv的变量，得写成sh 'APP_VERSION=${IMAGE_TAG} envsubst app.conf' - 如果配置文件本身是 YAML 或 JSON，
envsubst会破坏缩进或引号格式，此时不如用jq（对 JSON）或yq（对 YAML）
在 Helm Chart values.yaml 里动态填镜像版本
Helm 原生支持模板渲染，不需要额外脚本替换，但必须确保 values.yaml 中使用 {{ .Values.image.tag }} 这类模板语法，并在 helm install 时传入值。
- 推荐做法：把版本号作为参数传入，而不是改源
values.yaml文件：helm install myapp ./chart --set image.tag=${IMAGE_TAG} - 如果必须生成固定版
values.yaml（例如用于离线部署），可用yq工具：yq e ".image.tag = env(IMAGE_TAG)" values.yaml > values.prod.yaml - 注意
yqv4+ 语法和 v3 不兼容；v4 默认不修改原文件，需重定向输出；确认 CI 环境装的是yq而非老版本python-yq
构建镜像时把版本号编译进二进制或写入文件系统
某些语言（Go、Rust）支持构建时注入版本信息，比运行时替换配置更彻底，也避免配置文件被误改。
- Go 示例：
go build -ldflags "-X 'main.Version=${IMAGE_TAG}'" -o app main.go，然后在代码里读main.Version - Rust 示例：
cargo build --release --bin app --features version=${IMAGE_TAG}（需在build.rs中处理） - 通用兜底：构建阶段写入
/app/VERSION文件：echo "${IMAGE_TAG}" > VERSION && docker build -f Dockerfile .，Dockerfile 中COPY VERSION /app/VERSION - 这个方式的问题是：若镜像分层缓存生效，旧
VERSION文件可能被复用——务必在Dockerfile中把COPY VERSION放在尽可能靠后的位置，或加ARG BUILD_TIME强制刷新缓存
最容易被忽略的一点：所有替换操作必须发生在 docker build 之前，且不能依赖容器启动后才有的环境（比如 Kubernetes Downward API）。一旦镜像打好，里面的内容就固定了——所谓“动态”，只存在于构建流水线那一瞬间。
