如果你的项目是使用vite和uniapp配置开发的,就可以在代码里面获取到这些变量,但是开发,测试和发布是不同的请求地址,所以需要配置。Vite 使用 dotenv 从你的 环境目录 中的下列文件加载额外的环境变量:
javascript
.env # 所有情况下都会加载
.env.local # 所有情况下都会加载,但会被 git 忽略
.env.[mode] # 只在指定模式下加载
.env.[mode].local # 只在指定模式下加载,但会被 git 忽略
环境加载优先级:
一份用于指定模式的文件(例如 .env.production)会比通用形式的优先级更高(例如 .env)。
另外,Vite 执行时已经存在的环境变量有最高的优先级,不会被 .env 类文件覆盖。例如当运行 VITE_SOME_KEY=123 vite build 的时候。
.env 类文件会在 Vite 启动一开始时被加载,而改动会在重启服务器后生效。
根据vite文档,我们创建4个环境文件,注意,环境文件只能放在项目根目录上,否则不生效。
其中,development与prodution环境是内置的环境,对应的uni 、 uni build命令(运行,发行),test为自定义的模式。补充:
javascript
import.meta.env.MODE: {string} 应用运行的模式。
import.meta.env.BASE_URL: {string} 部署应用时的基本 URL。他由base 配置项决定。
import.meta.env.PROD: {boolean} 应用是否运行在生产环境(使用 NODE_ENV='production' 运行开发服务器或构建应用时使用 NODE_ENV='production')。
import.meta.env.DEV: {boolean} 应用是否运行在开发环境 (永远与 import.meta.env.PROD相反)。
import.meta.env.SSR: {boolean} 应用是否运行在 server 上。
我们在.env.testing 该自定义环境里定义几个变量 :
javascript
VITE_BASE_URL="http://192.168.31.212:9041/v1"
注意:定义的环境变量必须以 VITE_ 为前缀的变量才会暴露给经过 vite 处理的代码。
这里自定义的VITE_BASE_URL与VITE自带的变量BASE_URL有不同的含义,VITE中的BASE_URL代表的是该项目运行后的公共基础路径,通过uni cli的选项 --base去配置,而配置后的只则通过import.meta.env.BASE_URL去获取 ;而我自定义的VITE_BASE_URL本意则是记录后端的接口地址,不要混淆。
在项目中就可以拿到了:
javascript
onShow(() => {
console.log("App Show");
console.log("当前环境", import.meta.env.VITE_BASE_URL)
});
在编译的时候,配置一个新的脚本,并跟上: --mode test
javascript
//package.json
"scripts" : {
"test:h5": "uni --mode test"
}
自定义的环境模式只能通过uni cli 的选项 --mode {mode} 来实现,这也是为什么 使用HBuliderX cli 创建的项目不推荐使用.env,因为就算配置了.env文件,且确实在环境中可以拿到这些环境变量,但是只支持「运行」和「发行」对应的 .env.development 和.env.production ,如果我们想自定义一个test测试环境变量,是拿不到的,因为只能通过uni cli对应的mode选项标志去跑对应的环境,而HBuilderX无法配置mode
我们在package.json中加一条命令test:h5 ,然后在终端运行npm run test:h5 来运行该模式(当然也可以直接在npm run dev:h5 后直接加--mode)