环境变量:
- 会根据当前代码环境产生值的变化的变量就叫做环境变量
代码环境:
- 开发环境
- 测试环境
- 预发布环境
- 灰度环境
- 生产环境
举例:
百度地图 SDK,小程序的SDK
- APP_KEY: 测试环境和生产环境还有开发环境是不一样的key
开发环境: 110
生产环境:111
测试环境: 112
我们去请求第三方接口sdk接口的时候需要带上一个身份信息
假设是百度地图的API,获取用户位置:
- 伪代码
const getUserPosition = () => { axios.post({ params: { APP_KEY:110 // 如果这样写死,来回跳环境就很麻烦 } }) }类比环境变量来说:
我们在和后端同学对接的时候,前端在开发环境中请求的后端API地址和生产环境的后端API地址是一个吗? 肯定不是同一个
- 开发和测试: http://test.api/
- 生产: https://api/
获取用户信息
// baseUrl 是后端基础的服务器域名 axios.baseUrl = "http:test.api/" const getCurrenLoginUserInfo = () => { axios.get({ url: "/url/info" // baseUrl 会自动拼接 }) }创建两个环境配置文件:
- .env.development
APP_KEY = 110 BASE_URL = http://test.api/
- .env.production
APP_KEY = 112 BASE_URL = http://api/
环境变量的意义:
- 在执行 yarn build的时候自动去换配置属性值
在vite中的环境变量处理:
- vite内置了 dotenv这个第三方库
dotenv的作用:
- 第三方库,在启动项目(yarn dev 或者 yarn build)的时候就会去读 配置文件(去找当前目录下的 .env 文件)
- dotenv会自动读取 .env文件,并解析这个文件中的对应环境变量,并将其注入到process对象下
- process是node端关于当前的一个进程的一个对象
- 所以在vite.config.js中就可以通过process去访问到 env文件中的变量了
总结:通过vite内置 dotenv 中的process去注入环境变量
vite.config.js:会在node端运行
node端用的是comment.js规范,但是现在又没有给这个配置文件开es module规范,那为什么 node 在读取 vite.config.js的时候能够认识 import和 export default
原因:
- vite.config.js可以书写成esmodule的形式,这是因为vite在读取这个vite,config.js的时候会率先去node解析文件语法,如果发现是esmodule规范,就会直接将esmodule规范进行替换变成 commonjs 规范
node 端读出来是字符串,然后使用字符串 replace 替换方法,将所有的 类似 export default 全部换成 module.exports
在vite.config.js中使用process注入env文件中的环境变量
- 访问process变量
- 但是vite考虑带和其他配置的一些冲突我呢提,它不会直接注入到process对象下
补充:env文件是普通环境变量文件,是自动会被读取的,具体看后文
使用loadEnv方法,手动注入env环境变量:
涉及到vite.config.js中的一些配置:
- root
- envDir: 用来配置当前环境变量的文件地址(用这个变量来改当前环境的)
- 修改.env 文件所在目录,也就是说替换.env文件为其他文件
- 简单来说，就是vite编译是有生命周期的，读取环境变量是在读取配置文件之后。
- vite给我们提供了一些补偿措施:
- 我们可以调用vite的loadEnv来手动确认env文件
使用loadEnv方法注入:
第二个参数 envDir:
- process.cwd方法:
- 返回当前node进程的工作目录(当前执行命令(如yarn dev)的目录)
- 写工作目录字符串也可以
第三个参数 perfixes:
- env的文件名: .env是默认值,可以不传
此时可以发现,我们手动注入了env中的环境变量:
为了防止冲突，appkey不会直接放入，而是通过loadEnv手动确认导入，才进行放置。
现在只会读取配置文件中以VITE_开头的配置了，其他的包括node注入进来的都不会被读取
此时可以在服务端根据不同环境做一些处理了
.env:
- 所有环境都需要用到的环境变量
.env.development:
- 开发环境需要用到的环境(默认情况下vite将我们的开发环境取名为 development)
.env.production:
- 生产环境需要用到的环境变量(默认情况下vite将我们的生产环境取名为 production)
mode变量
- yarn dev的时候
- vite默认会把mode设置成development
- vite会将命令后面的 后缀 --mode development 传递给方法中的mode形参（将mode设置为 development传递进来）
- yarn build：
- vite默认会把mode设置为production
- 同样可以通过后缀 --mode，改变默认值
总结：mode区分开发环境还是生产环境，可根据输入指令有默认值，但可手动修改
通过mode，vite就会默认去找 env.development 文件
当我们调用loadenv的时候，会做如下几件事：
- 直接找到 .env 文件,并解析其中的环境变量，并放进一个对象里
- 会将传进来的mode这个变量的值进行拼接： ".env.development" ，并根据我们提供的目录去取对应的配置文件并进行解析，并放进一个对象
- 理解为：
const baseEnvConfig = 读取 .env 的配置
const modeEnvConfig = 读取env相关配置
// 如果对象中有重复变量,后面的覆盖前面的
const lastEnvConfig = {...baseEnvConfig, ...modeEnvConfig}上述操作只是在 vite.config.js中配置
如果是客户端, vite会将对应的环境变量注入到import.meta.env里去
在request中如何使用，也就是我配置axios,如何使用不同的环境变量
将环境变量带到客户端中:
举例：将环境变量带到axios请求中
注意：
vite做了一个拦截，为了防止我们将隐私性的变量直接送进import.meta.env中，所以做了一层拦截，如果你的环境变量不是以vite开头的，它就不会帮你注入到客户端中去
- 给环境变量添加 VITE_ 前缀，此时就可以调用了
- 假如环境变量并没有添加 VITE_ 前缀，就不会注入到客户端
- 效果如下：
修改默认前缀：
- 使用 envPrefix 去配置
- 效果如下
完整配置项如下：
- 恍然大悟啊
上面，我们配置了一个test环境，那么如何访问test环境呢？
- 如下：
现在我们已经知道如何配置环境变量了，就是防止我们去手动反复的去改一些vite中环境变量的配置
