一、前端开发里的“隐形炸弹”——敏感信息泄露的日常痛

1.1 直接写代码里的致命坑

很多前端开发者刚入行时，习惯把需要配置的信息（比如测试API密钥、第三方登录ID）直接写在JS代码里。比如做调用AI接口的项目，直接在axios请求里写密钥，然后提交到git仓库——哪怕是私仓，万一被内部人员导出，或不小心推到公仓，都会导致核心信息泄露，给公司带来损失。更麻烦的是，换开发、测试、生产环境就要反复改代码，很容易改错，效率极低。

二、Vite给的“专属私密抽屉”——import.meta.env

2.1 到底什么是import.meta.env？

你可以把Vite理解成项目的“专属管理员”，它准备了一个只有项目本身能打开的私密抽屉，用来存放和运行环境挂钩的变量。你可以告诉Vite：哪些变量要放进这个抽屉，哪些绝对不能放，这样就能避免敏感信息跟着代码泄露。

2.2 两步搞定基础用法

技术栈：Vite + JavaScript

第一步是创建环境变量文件，Vite会自动识别命名规则，比如.env（通用）、.env.development（开发）、.env.production（生产），变量必须以VITE_开头（Vite才会把它们放进私密抽屉，前端代码能读取），用#写注释，示例如下：

# .env.example （提交到git，仅当占位符参考）
# 开发环境变量（本地配置，不提交git）
VITE_API_BASE_URL=http://localhost:8080/dev-api
VITE_APP_NAME=本地测试项目

# .env.development （本地专属，加入.gitignore不提交）
VITE_API_BASE_URL=http://localhost:8080/dev-api
VITE_APP_SECRET=abc123dev（仅本地开发用）

# .env.production （生产环境，部署时由运维配置）
VITE_API_BASE_URL=https://api.yourapp.com/prod-api
VITE_APP_CLIENT_ID=123456prod（第三方登录用）

第二步是在代码里读取变量，用import.meta.env.VITE_变量名的格式，比如写API请求的工具文件：

// api.js 示例代码
// 读取Vite私密抽屉里的环境变量
const API_BASE_URL = import.meta.env.VITE_API_BASE_URL;
const APP_NAME = import.meta.env.VITE_APP_NAME;

// 封装通用GET请求，自动用当前环境的API地址
export const fetchCommonData = async (path) => {
  const response = await fetch(`${API_BASE_URL}/${path}`);
  return response.json();
};

第三步是配置不同环境的启动脚本，在package.json里添加对应命令，Vite会自动根据命令加载对应模式的环境变量：

{
  "name": "vite-demo",
  "version": "1.0.0",
  "scripts": {
    "dev": "vite", // 自动加载.env.development
    "build": "vite build", // 自动加载.env.production
    "build:test": "vite build --mode test" // 自定义测试环境，加载.env.test
  }
}

三、细节拉满的用法指南（全场景覆盖）

3.1 环境文件的安全配置

所有.env开头的文件必须加入.gitignore，绝对不能提交到git，只需要提交.env.example（占位符）给其他开发者参考，他们克隆项目后，自己创建本地的.env.development，避免把个人密钥推到远程仓库，.gitignore的配置示例：

# 忽略所有环境变量文件
.env
.env.local
.env.development.local
.env.test.local
.env.production.local

3.2 自定义模式的灵活使用

如果需要新增测试、预发布等环境，只要创建对应命名的环境文件（比如.env.test），再在package.json里添加带--mode参数的命令即可，不用改一行代码就能切换到对应环境的配置。

3.3 环境变量的优先级

Vite的环境变量优先级从高到低是：命令行参数（比如--mode test）> 对应模式的环境文件（比如.env.test）> 通用.env文件，避免变量冲突时出错。

四、不得不注意的“红线”（踩坑必中）

4.1 敏感变量绝对不能加VITE_前缀

带VITE_前缀的变量会被打包到前端客户端代码里，变成明文，所以绝对不能放核心敏感信息（比如数据库密码、支付密钥），这些必须放在后端服务的环境变量里，前端只能通过后端接口获取非敏感数据，绝对不能直接存储核心密钥。

4.2 变量名不能写错前缀

如果定义的变量没有加VITE_，代码里用import.meta.env.变量名是读不到的，Vite只会暴露带VITE_的变量，这是新手最常犯的错误，一定要注意。

4.3 不要混用前端和后端的环境变量

前端环境变量只能用来放客户端需要的配置（比如API地址、第三方ID），后端环境变量用来存服务端专属的敏感信息，两者要完全隔离，不能混淆。

五、这套方案的“利与弊”

5.1 优点

  1. 原生支持，不用额外装插件，配置简单，几分钟就能搞定；
  2. 防误提交，通过.gitignore避免本地敏感文件推到远程，大幅降低泄露风险；
  3. 模式灵活，支持自定义任意环境，不用改代码就能切换配置；
  4. 热更新，修改.env文件后，Vite开发服务器自动生效，不用重启，提升开发效率。

5.2 缺点

  1. 带VITE_的变量在生产打包后是明文，不能放核心敏感信息，只能放半敏感或非敏感配置；
  2. 对于复杂的多环境配置，需要手动管理环境文件，不过用.env.example可以统一管理占位符，降低成本；
  3. 不能完全替代后端环境变量，核心敏感信息必须由后端处理，前端仅作为配置入口。

六、实际项目中的应用场景

6.1 API地址的环境切换

最常见的场景，开发时用本地Mock或本地服务的API，生产用正式API，测试用测试API，通过Vite的模式切换，不用每次改代码里的API地址，大幅减少出错概率。

6.2 第三方登录的配置

比如做微信、QQ登录，开发时用测试号的APP_ID，生产用正式号的APP_ID，把APP_ID放在环境变量里，不同环境用不同的，避免把测试号ID当成正式的提交，提升项目安全性。

6.3 避免敏感信息泄露

公司内部的专属API密钥放在.env.development里，不加入git，就算项目开源，也不会泄露敏感信息，其他开发者克隆项目后，自己配置本地的.env.development，就能正常开发，不用依赖别人的配置。

七、总结

前端开发中，敏感信息泄露是非常常见的痛点，很多开发者因为直接把配置写在代码里，带来安全风险。Vite的import.meta.env和环境变量文件的组合，是一套简单实用的解决方案，它通过隔离配置和代码、区分环境、防止敏感文件提交，有效避免敏感信息泄露，提升项目的安全性和可维护性。不管是个人项目还是团队项目，这套方案都能快速上手，解决实际开发中的核心问题。