同一构建适配多环境：React(Vite)应用K8s部署环境变量配置问题

为什么你之前的单镜像注入方案失效？ #

Vite 默认会在构建阶段将带VITE_前缀的环境变量硬编码到静态产物中，浏览器运行时无法直接读取容器层面注入的环境变量——两者处于完全独立的运行上下文，这是导致方案失效的核心原因。

业内两种主流方案对比 #

1. 每个环境单独构建产物（主流首选） #

• 操作方式：利用Vite原生的多环境配置机制，创建.env.development、.env.staging、.env.production等环境文件，分别写入对应环境的API地址、Azure AD应用ID/租户ID；构建时通过vite build --mode <环境名>指定环境，生成专属静态产物后打包为对应环境的Docker镜像（或用不同标签区分）。
• 核心优势：完全贴合Vite的设计逻辑，无需额外改造代码，产物直接适配目标环境，运行时无额外加载开销；不同环境可做差异化构建配置（比如生产环境开启更严格的代码压缩、混淆）。
• 适用场景：环境数量较少（如dev/staging/prod）、需要严格隔离各环境产物的场景。

2. 运行时注入环境变量（需代码改造） #

如果坚持要用单镜像适配多环境，需要对应用和容器做以下改造：

• 容器端处理：编写启动脚本，在容器启动时用envsubst等工具，将K8s注入的环境变量替换到一个预定义的config.template.js模板中，生成静态的config.js文件（内容示例：window.__APP_CONFIG__ = { API_URL: "${API_URL}", AZURE_CLIENT_ID: "${AZURE_CLIENT_ID}" }）。
• 前端代码改造：在React入口文件（如main.jsx）中引入生成的config.js，通过window.__APP_CONFIG__读取配置项，替代原来直接使用import.meta.env的方式。
• 核心优势：单个镜像适配所有环境，减少镜像维护成本，构建流程统一。
• 注意事项：要确保启动脚本正确完成变量替换，同时需处理好前端初始化时的配置加载时机，避免因配置未就绪导致的报错。

方案选择建议 #

如果你的环境数量不多（3个以内），优先选择每个环境单独构建的方案，实现成本更低、稳定性更高；如果需要频繁新增环境或追求镜像复用效率，再考虑运行时注入的改造方案。

内容的提问来源于stack exchange，提问作者Kevimuxx69