对背后的运行方式、安全红线还有生产环境的动态部署一知半解，导致项目上线后出现敏感信息泄露或接口请求错误等痛点。话说回来，

这篇文章结合公司级项目的真实场景。一次性把 Vite 的环境变量彻底讲透，帮助你从“会用”升到“精通”。

再看主要概念，Vite 内置的 dotenv 机制

需要手动安装 dotenv 来解析 .env 文件。而在 Vite 中，这一切已被内置。Vite 自动集成了 dotenv 与 dotenv-expand能够直接读取项目根目录下的环境配置文件。

使用者痛点：开发时不小心把数据库密码、私钥等敏感信息写进前端代码，导致泄露风险。

主要安全红线：只有以 VITE_ 为前缀的变量才会被暴露给客户端代码。话说回来，其他变量始终只在 Node 环境可见。

# .env
VITE_API_BASE_URL=https://api.example.com # ✅ 会暴露给前端
DB_PASSWORD=secret123 # ❌ 不会暴露。前端读取为 undefined

至于文件加载机制，一半固定，一半自定义

Vite 的环境变量文件必须放在项目根目录，加载遵循“合并与覆盖”规则。

. 基础与模式文件

• .env所有环境都会加载的公共基础配置。
• .env.development执行 npm run dev 时加载。
• .env.production执行 npm run build 时加载。

. 自定义模式

除了上述固定文件，还可以自行创建如 .env.test/.env.staging 等自定义模式，只需在脚本中通过 --mode 指定即可：

{
"scripts": {
"dev"的观点是，"vite","build": "vite build"。"build:test": "vite build --mode test" // 会加载 .env.test
}
}

. 加载优先级 & 本地私有配置

执行建立时Vite 按顺序加载：

1. .env
2. .env.{mode}
3. .env.local
4. .env.{mode}.local

If 同名变量出现冲突，后加载的文件会覆盖前面的值。User Pain Point： 本地调试时经常忘记把私有配置提交到仓库，导致同事 CI/CD 报错。解决办法是将 .env.local* 加入 .

生产环境动态 IP 部署方案

#1 在 .env 中统一使用相对方法前缀

# .env.development
VITE_API_BASE_URL=/dev-api
# .env.production
VITE_API_BASE_URL=/api

#2 Axios封装中引用该变量

const request = axios.create({
baseURL: import.meta.env.VITE_API_BASE_URL。// 自动取相对方法
timeout: Number || 5000,});

#3 Nginx 反向代理实现“一次打包，到处运行”

不论项目部署在 http://10.1.2.3:8080/​ 。/​ ,或者正式域名，都只需要在 Nginx 中把统一前缀转发到真实后端 IP 即可：

location /api {
proxy_pass http://真实后端IP:端口;proxy_set_header Host $host;}

User Pain Point： 以前很多团队把完整域名写死在代码里现场更换服务器后只能紧急改代码并重新建立，耗时又出错。采用相对方法 + Nginx 转发后只需修改运维层配置即可。 话说回来，

运行环境的本质差异： vs

User Pain Point： 在 vite.config.js 中直接使用 import.meta.env 报错。因为该对象只在浏览器代码里生成。

• import.meta.env
• 运行于浏览器。打包阶段 Vite 会把所有出现的 import.meta.env.VITE_XXX 静态替换为对应字符串，仅限于 src/ 下业务代码。
• loadEnv
• Node 环境下执行，在 Vite 启动之前读取 .env 文件。用于 vite.config.js、插件或自定义脚本中获取变量。

loadEnv 参数详解

import { defineConfig,loadEnv } from 'vite';export default defineConfig => {
// mode 为当前执行模式。如 development、production、test 等
const env = loadEnv,'');// 第三参数为空表示读取全部变量
return {
说到define。{
__APP_SECRET__: JSON.stringify,},//…其他 Vite 配置
};})，不过，

process.cwd 获取的是执行 Node 命令时所在目录。也就是项目根目录，确保能准确定位 .env 文件。

E公司级项目标准配置模板

# 应用标题，用于页面 title 动态拼接
VITE_APP_TITLE=公司级管理程序
# 接口统一前缀
VITE_API_BASE_URL=/api
# 接口请求超时时间
VITE_API_TIMEOUT=8000

. 开发环境（ . env . development )

# 是否开启 Mock 数据
VITE_ENABLE_MOCK=true
# 是否打印调试日志
VITE_ENABLE_DEBUG=true
# 覆盖基础 API 前缀。直连测试服务器
VITE_API_BASE_URL=/dev-api

. 生产环境（ . env . production )

# 发布关闭 Mock 与调试日志
VITE_ENABLE_MOCK=false
VITE_ENABLE_DEBUG=false
# 保持相对方法，由 Nginx 转发至真实后端
VITE_API_BASE_URL=/api

路由元信息中定义 title

const routes =;

主入口监听路由变化并拼接全局标题

import router from './router';router.afterEach => {
const defaultTitle = import.meta.env.VITE_APP_TITLE;document.title = to.meta.title?`${to.meta.title} - ${defaultTitle}` : defaultTitle;})，

This pattern keeps default title in a single place while allowing each page to specify its own subtitle,which is exactly what large‑scale admin systems need.

• 了解并正确使用 *. env*、*. env.{mode}* 与 *. env.local* 的加载顺序；不过，
• 仅以 VITE_ 前缀暴露给浏览器。实现安全隔离，
• 区分客户端 和服务端 两种读取方式；话说回来，
• 采用相对方法 + Nginx Reverse Proxy。实现“一次建立，多地部署”；
• 使用路由 meta + 环境变量实现动态页面标题，提高使用者体验和维护性。

---