package.json 的 uni-app.scripts.env 是最稳定通用的多环境配置方式；变量名必须以 vue_app_ 开头，uni_platform 需显式指定，读取时须加默认值兜底，避免 undefined 拼接导致 404。
uni-app 支持多环境变量，但不同配置方式生效范围和时机差异很大——.env 文件只在 cli 或 hbuilderx 4.25+ 的 vue3 / uniapp x 项目中有效；package.json 的 uni-app.scripts.env 是微信小程序/h5 多环境最稳定、最通用的方式；而 vue.config.js 配置仅对 webpack 构建生效，且需手动注入，容易漏掉 defineplugin 设置。
用 package.json 的 uni-app.scripts 定义编译模式
这是目前兼容性最好、无需额外依赖、HBuilderX 和 CLI 均原生支持的方式。关键在于把环境标识和变量都塞进 env 对象里，且变量名必须以 VUE_APP_ 开头（UniApp 编译时才会自动注入到 process.env）。
常见错误现象：process.env.VUE_APP_BASE_URL 在代码里是 undefined，但配置明明写了——大概率是变量名没加 VUE_APP_ 前缀，或没在 uni-app.scripts 下定义，而是写在了顶层 scripts 里。
-
UNI_PLATFORM必须显式指定，比如"mp-weixin"或"h5"，否则 HBuilderX 可能无法识别编译目标 -
title会显示在 HBuilderX 运行菜单中，建议包含环境名（如“微信小程序——测试版”），避免误点 - 多个环境之间不要共用
env键名但值不同，比如同时定义VUE_APP_DEBUG: true和VUE_APP_DEBUG: false，构建时后者会覆盖前者
在代码中安全读取 process.env 变量
Vue3（非 H5 端）只能直接访问 process.env.VUE_APP_*，不能通过 import.meta.env 或 import.meta.env.VUE_APP_*；H5 端则两者都支持，但推荐统一用 process.env 写法，减少平台差异。
容易踩的坑：直接写 process.env.VUE_APP_BASE_URL + '/login'，一旦变量未注入就会拼出 undefined/login，请求 404。必须加兜底逻辑。
- 始终用逻辑或
||提供默认值：const baseUrl = process.env.VUE_APP_BASE_URL || 'https://prod.example.com' - 避免在
data()或setup()顶层直接赋值，应在请求发起前实时读取，防止环境变量在热更新后未刷新 - 不要在
onLoad之前就初始化全局 axios 实例并固化baseURL，应封装成函数调用时才取值
.env 文件只在特定项目类型中可用
.env 方案看似简单，但实际限制最多：仅适用于 HBuilderX 中创建的 UniApp Vue3 / UniApp X（4.25+）项目，以及 CLI 创建的项目；Vue2 项目、旧版 HBuilderX、或使用 vue.config.js 自定义 Webpack 的项目，.env 文件会被完全忽略。
另一个常被忽略的点：.env 文件中的变量**必须以 VUE_APP_ 开头**才能被注入。写 API_URL=xxx 是无效的，必须写成 VUE_APP_API_URL=xxx。
-
.env是基础配置，会被所有模式加载；.env.development和.env.production仅在对应NODE_ENV下生效，但 uni-app 的dev模式不等于NODE_ENV=development，所以优先级不如package.json显式控制可靠 - 如果同时用了
package.json和.env，前者定义的同名变量会覆盖后者，不要指望它们叠加 -
.env.local不会被 Git 跟踪，适合放本地调试用的密钥，但切勿在其中写影响构建结果的逻辑配置（如开关功能）
真正复杂的地方不在怎么配，而在于「环境标识如何贯穿整个流程」：从 package.json 定义 → 构建工具注入 → 运行时读取 → 请求层拼接 → 错误监控上报，每个环节都可能因平台差异或缓存导致变量丢失。最稳妥的做法，是把所有环境相关逻辑收敛到一个配置文件里，用 switch (process.env.ENV_TYPE) 显式分发，而不是散落在各处靠字符串判断。
