uni-app 默认不走 Babel 转译，babel.config.js 无效；其编译由 vue-cli-plugin-uni 或 HBuilderX 直接解析 AST 生成平台代码，绕过 Webpack+Babel 链路。
uni-app 默认不走 Babel 转译流程，babel.config.js 或 .babelrc 文件在标准 uni-app 项目中会被忽略——这是最常被踩的坑，也是你“配了没用”的根本原因。
uni-app 的构建链路根本不经过 Babel
uni-app 的编译核心是自家的 vue-cli-plugin-uni（CLI 项目）或 HBuilderX 内置编译器（可视化项目），它直接将 .vue 文件解析为 AST，再按目标平台（如微信小程序、H5）生成对应代码。整个过程绕过了 Webpack + Babel 的标准前端构建链路，所以你写的 babel.config.js 对 script 块里的 ES6+ 语法完全无效。
- 只有显式启用 Webpack 构建（比如通过
vue.config.js自定义配置并强制接入 Webpack）时，Babel 才可能生效 - 但这么做会破坏 uni-app 的平台适配逻辑，导致
uni.xxxAPI 编译异常、条件编译失效、甚至pages.json解析失败 - H5 平台虽基于 Webpack，但默认使用的 preset 是
@dcloudio/vue-cli-plugin-uni/packages/webpack-config-h5，它内部已固化了 target（通常为 Chrome 49+），不读取你的 Babel 配置
真正影响旧手机兼容性的其实是平台 target 和 polyfill 策略
旧手机（尤其是 Android 4.x、iOS 9–10）出问题，90% 不是因为箭头函数或解构语法，而是：Promise、Array.from、Object.assign、fetch 等 API 缺失，以及 CSS 中的 flex 行为差异、position: fixed 滚动错位等。
- H5 端：在
vue.config.js中设置configureWebpack.optimization.splitChunks.chunks = 'all'并配合core-js@3按需注入，比改 Babel 更有效 - 小程序端：完全不用考虑 Babel，因为运行环境是微信/支付宝自己的 JSCore，它们对 ES6 支持度远高于 Android WebView；真正要防的是
async/await在低版本基础库中未被转译（需确认mp-weixin的libVersion≥ 2.10.4） - App 端（app-plus）：Android 4.4+ 使用系统 WebView，必须开启
build.universal并在manifest.json中设"splashscreen": {"autoclose": true}，否则部分 Promise polyfill 无法及时加载
如果硬要加 Babel（仅限 H5 且明确知道后果）
仅当你的项目是 CLI 创建、且已通过 vue.config.js 接入自定义 Webpack 配置时，才可局部启用 Babel：
- 安装
@babel/preset-env和core-js@3 - 在
vue.config.js的configureWebpack.module.rules中，为.js和.ts文件显式添加babel-loader，注意排除node_modules和uni_modules -
必须关闭 uni-app 自带的 JS 压缩：在
vue.config.js中设configureWebpack.optimization.minimize = false，否则 Terser 会把 Babel 输出的 helper 函数二次破坏 - 验证方式：构建后打开
dist/build/js/app.js，搜索_classCallCheck或_defineProperty，存在即生效；但你要承担页面白屏、uni.getSystemInfo返回undefined的风险
真正卡住旧手机的，从来不是 const 和 let，而是 Promise 没兜底、IntersectionObserver 直接报错、或者一个没加 user-select: none 的按钮在 Android 4.4 上被双击放大。与其折腾 Babel，不如在 main.js 开头 import 'core-js/stable'，再用 uni.getSystemInfo 动态降级功能——这才是 uni-app 场景下可控、可测、可回滚的做法。
