登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  前端

Vite mode 文件选择后为什么生产构建仍读取旧值

来源:17golang原创

时间:2026-09-08 23:56:22 204浏览 收藏

Vite 生产构建还在读取旧值,通常不是 mode 文件“失效”,而是命令实际使用的 mode、进程环境变量或旧的构建产物没有对上。vite build 默认使用 production mode;如果要读取 .env.staging,必须明确执行 vite build --mode staging。另外,已经存在于启动进程里的环境变量优先级最高,会覆盖同名的 env 文件值。

要点速览
  • --mode 决定加载哪一组 .env.[mode] 文件,不能只改文件名后期待生产命令自动切换。
  • NODE_ENV 和 Vite mode 是两条概念线;vite build --mode development 仍然可以保持生产构建语义。
  • 改完 env 文件要重启 dev server,并清楚区分新构建目录、旧 dist 和部署端缓存。

先把 mode、NODE_ENV 和构建命令分开

排查时先写下真正执行的命令,不要只看文件夹里有哪些 env 文件。默认情况下,vite dev 使用 development mode,vite build 使用 production mode。命令里的 --mode 可以切换环境文件,例如 vite build --mode staging 会寻找 .env.staging

NODE_ENV 是另一条线。vite build --mode development 的 mode 是 development,但构建命令仍可能把 NODE_ENV 视为 production;反过来,NODE_ENV=development vite build 也不代表 mode 自动变成 development。把这两个值打印或写进构建日志,往往比反复改文件名更快。

Vite 构建命令、mode、NODE_ENV 与环境文件选择关系图
图1:横向查看构建命令、mode 与环境文件之间的静态关系,区分 `--mode` 选择和 `NODE_ENV` 语义。

按优先级核对 Vite 实际读取的文件

Vite 会加载通用的 .env.env.local,以及当前 mode 对应的 .env.[mode].env.[mode].local。mode 专属文件对同名变量优先,但只在专属文件出现的变量不会让通用文件里的其他变量消失。最容易被忽略的是:执行命令时已经存在的进程环境变量拥有更高优先级。

检查对象示例它决定什么
构建命令vite build --mode staging当前 mode 与专属 env 文件
通用文件.env.env.local所有 mode 可用的基础变量
mode 文件.env.staging该 mode 的同名覆盖值
进程变量VITE_API_BASE=https://new.example npm run build最高优先级的临时覆盖

因此,“我已经把值改成 staging 了”还不够。要同时确认 npm script 有没有偷偷传入 NODE_ENVVITE_*,shell、CI 平台和容器编排文件也可能提前设置同名变量。

配置文件读取与前端代码读取不是同一时机

业务代码里通常通过 import.meta.env.VITE_API_BASE 读取变量,它会在构建时被替换进前端产物。若 vite.config.ts 需要根据 mode 改 alias、代理或插件选项,不能把配置阶段的 import.meta.env 当成已经加载好的对象,应使用 loadEnv 显式读取。

import { defineConfig, loadEnv } from 'vite'
import { fileURLToPath, URL } from 'node:url'

export default defineConfig(({ mode }) => {
  // 配置阶段显式加载当前 mode 的环境变量。
  const env = loadEnv(mode, process.cwd(), 'VITE_')

  return {
    resolve: {
      alias: {
        // 只把非敏感的前端公开变量用于配置选择。
        '@api': fileURLToPath(new URL(env.VITE_API_BASE, import.meta.url)),
      },
    },
  }
})

示例里的 loadEnv(mode, process.cwd(), 'VITE_') 只读取带 VITE_ 前缀的公开变量;它不应成为把数据库密码、私钥等秘密送进浏览器的理由。Vite 官方也提醒,暴露给客户端的变量会进入 bundle,敏感配置应放到后端或服务端函数中。

Vite loadEnv 配置阶段与 import.meta.env 构建替换边界图
图2:看清 `vite.config`、`loadEnv`、`import.meta.env` 与 `dist` 的静态边界,避免把配置阶段和客户端替换阶段混为一谈。

改值后仍旧时,按这张清单收尾

先停掉旧的 dev server,再用明确的 --mode 重启;因为 env 文件是在启动时加载的,运行中的进程不会自动刷新。生产构建则要确认实际部署的是本次生成的 dist,不要只在本地看到新值就判断线上已更新。

  • 命令:记录完整的 npm script 和最终展开的 Vite 参数。
  • 文件:确认当前工作目录里确实有目标 .env.[mode],并检查同名的 shell 或 CI 变量。
  • 产物:在新的构建目录中搜索非敏感的 VITE_API_BASE 结果,区分旧目录、浏览器缓存和部署缓存。

这套排查能把“Vite 读取旧值”拆成可验证的三件事:选错 mode、优先级被覆盖,或实际使用了旧进程/旧产物。只有当这三层都排除后,才值得继续看插件、自定义 envDir 或部署平台的额外处理。

常见问题

.env.production 改了,为什么 vite dev 不变?

因为 dev server 默认是 development mode,优先看 .env.development 及通用文件;切换到 production mode 或把变量放到正确的文件后,还要重启 dev server。

--mode staging 会自动把 NODE_ENV 变成 staging 吗?

不会。它主要改变 Vite mode 和对应 env 文件;NODE_ENV 仍由命令、环境或 env 文件单独决定。

为什么不建议把所有配置都写成 VITE_*

带此前缀的变量会暴露给浏览器代码,适合公开接口地址等非敏感配置,不适合 API 密钥、数据库密码和私钥。

可继续查阅 Vite 的 环境变量与 mode 文档以及 CLI 参数说明,重点核对命令中的 mode、实际工作目录和进程环境变量。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>