如果你的项目是使用vite和uniapp配置开发的，就可以在代码里面获取到这些变量，但是开发，测试和发布是不同的请求地址，所以需要配置。Vite 使用 dotenv 从你的 环境目录 中的下列文件加载额外的环境变量：
.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为自定义的模式。补充：
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 该自定义环境里定义几个变量 ：
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本意则是记录后端的接口地址，不要混淆。
在项目中就可以拿到了：
onShow(() => {
console.log("App Show");
console.log("当前环境", import.meta.env.VITE_BASE_URL)
});
在编译的时候，配置一个新的脚本，并跟上： --mode test
//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）