uniapp打包微信小程序插件接入全流程与高频踩坑指南

做 uniapp 打包微信小程序这活儿，最磨人的从来不是写页面，而是配置不对、插件接不上、包打出来丢进开发者工具直接白屏。前前后后折腾了二十来个版本，踩了不少坑之后，我把整个流程里该注意的地方都捋了一遍。这篇文章就围绕“uniapp 打包微信小程序用插件”这条主线，把项目创建、插件接入、开发者工具联调这一整条链路讲清楚，同时把顶部导航栏高度适配、登录获取手机号、自定义分享这些高频需求一并带上。无论你是刚开始接触 uniapp 的新手，还是已经写了一阵子想系统理清配置老手，这篇对你应该都有参考价值。

1. 先搞清楚 uniapp 打包小程序到底做了什么

1.1 编译链路：从 Vue 代码到微信小程序的 wxml

很多新手容易把 uniapp 打包微信小程序理解成“复制粘贴”，实际上它是一套完整的编译链路。uniapp 本身是基于 Vue 语法的一层跨端框架，当你执行打包命令时，编译器会把.vue组件里的 template、script、style 三块内容分别转换成微信小程序的 wxml、wxss、js 和 json 四个文件类型。这意味着，你在 Vue 里写的v-if、v-for、:bind这些语法，最终都会被编译成微信小程序能识别的wx:if、wx:for、bindtap等对应形式。

这个编译过程还自带一套条件编译机制。比如你在代码里写：

// #ifdef MP-WEIXIN console.log('这段代码只会出现在微信小程序端') // #endif

那么在打包到微信小程序时，编译器只保留这段代码；打包到 H5 或其他端时，这整段会被直接剔除。条件编译是实现“一套代码、多端适配”的核心手段。实际操作中，我用它处理过大量平台差异，比如微信小程序独有的分享回调、字节小程序独有的广告组件等，都靠这套机制做了隔离。

编译完成后，产物会输出到项目根目录的dist文件夹下。如果你用的 HBuilderX，运行模式会生成dist/dev/mp-weixin，发行模式生成dist/build/mp-weixin；如果你用 CLI 工程（即通过 vue-cli 创建的 uniapp 项目），则统一生成dist/build/mp-weixin或dist/dev/mp-weixin，具体取决于你执行的是npm run dev:mp-weixin还是npm run build:mp-weixin。

1.2 小程序平台的特殊性：为什么不能直接跑在开发者工具里

微信小程序有一套自己的运行环境，它不像网页那样直接通过 URL 访问，而是必须先在微信开发者工具中导入项目目录，然后由开发者工具加载渲染。uniapp 编译出来的mp-weixin目录就是准入门票，这个目录下会生成一个project.config.json，里面带有miniprogramRoot字段，告诉微信开发者工具“我的代码在这个子目录下”。

正因为有了这层转换，你就不能直接把 uniapp 项目根目录拖进微信开发者工具，否则会提示项目结构不正确。正确做法是：打开微信开发者工具，选择“导入项目”，目录选中dist/dev/mp-weixin或dist/build/mp-weixin，然后填入你的小程序 AppID。这里有个经验是，运行模式下每次修改代码后 dist 目录会被清空重写，开发者工具此时会自动刷新，但偶尔会遇到刷新不及时，手动点一下工具栏的“编译”按钮最靠谱。

1.3 manifest.json 里的 mp-weixin 配置项拆解

manifest.json是整个 uniapp 项目的全局配置，打包到微信小程序时，编译器会读取mp-weixin节点下的配置，转换成小程序的app.json和project.config.json。这块是最容易踩坑的地方，因为很多配置项跟纯微信原生开发时的写法完全不同。

我列一个实际场景中必调的清单：

{ "mp-weixin": { "appid": "wx你的小程序AppID", "setting": { "urlCheck": false, "es6": true, "minified": true, "postcss": true }, "usingComponents": true, "permission": { "scope.userLocation": { "desc": "你的位置信息将用于小程序定位服务" } }, "requiredPrivateInfos": ["getLocation"], "lazyCodeLoading": "requiredComponents" } }

appid不用多说，填错了开发者工具里会报域名校验失败或者无法预览。urlCheck是开发调试时的关键项，设置为 false 表示“不校验合法域名”，否则你在开发环境请求任何不在白名单里的接口都会被拦截；但注意，这个设置会被真机预览时覆盖，真机预览默认走微信后台的合法域名配置，所以上线前必须把接口域名配好。lazyCodeLoading是微信开发者工具编译优化选项，能减少小程序启动时的代码注入量，实测对冷启动速度有肉眼可见的提升。

2. 插件生态选型：uni_modules、npm 还是小程序原生插件

2.1 三种插件形态的本质区别

uniapp 里说的“插件”，跟微信小程序原生生态里的“插件”，严格说不是同一个东西。我刚接触那会儿就在这里绕了很久。

• uni_modules插件：这是 uniapp 官方设计的插件分发格式，本质还是一个 npm 包结构，但多了uni_modules目录约定和package.json里的专属字段。它的优势是 HBuilderX 可以直接从插件市场一键导入，不需要手动配 npm 依赖。
• npm 插件：就是常规的 npm 依赖，比如uview-plus、lime-echart这类 UI 库或工具库，通过npm install安装后在代码里import使用。打包时会作为普通依赖被打进产物。
• 小程序原生插件：这是微信小程序独有的“插件”概念，通常指微信公众平台审核通过后，由第三方开发者发布的功能模块，比如地图、支付、OCR 等。使用原生插件必须先在微信公众平台“设置-第三方设置-插件管理”中添加插件，然后在 uniapp 的manifest.json里配置plugins字段。

2.2 原生插件的接入流程：provider 和 version 是关键

微信小程序原生插件的接入方式比较特殊，跟普通 npm 包完全不是一个套路。先看一个实际的manifest.json配置：

{ "mp-weixin": { "appid": "wx你的AppID", "plugins": { "myPlugin": { "version": "1.0.0", "provider": "wx1234567890abcdef" } } } }

这里的provider必须填插件的 AppID，而不是你自己的小程序 AppID。这个坑太常见了，我看到很多人把自家小程序 AppID 填进去，编译时不会报错，但运行起来插件完全不生效。version是插件发布的版本号，必须是插件在微信公众平台上确实存在的版本，否则真机运行会提示“插件版本不存在”。

配置好之后，在代码里怎么调用原生插件呢？微信原生的调用方式是requirePlugin('插件名')，在 uniapp 里也是一样的：

const myPlugin = requirePlugin('myPlugin')

这里要注意一个细节，requirePlugin在 uniapp 的 H5 端和小程序端行为不一致。如果你在同一个文件里同时想兼容多端，建议用条件编译包一层：

// #ifdef MP-WEIXIN const myPlugin = requirePlugin('myPlugin') // #endif

否则 H5 端编译时会在requirePlugin这一步直接报找不到模块的错误。

2.3 选型建议：什么时候用原生插件，什么时候用 uni_modules

从我自己的项目经验来看，选插件的优先级应该是这样的：

选型时有一个“反直觉”的注意力点：原生插件往往是整个小程序包体积膨胀的元凶。微信小程序主包体积限制是 2 MB，单个原生插件本身就有体积，再加上编译后的代码，很容易超限。所以在引入原生插件前，先看插件详情页的“大小”字段，超过 500 KB 的就要慎重，除非业务确实绕不开。

我记得有个项目，光地图插件就占了 800 KB，主包直接爆了，后来改用 uniapp 自带的 map 组件才解决。这个经验就是：uniapp 内置了很多原生能力，很多第三方插件能做到的事，内置组件也能做，而且不增加额外体积。

3. 从源码到微信小程序包：完整打包操作流程

3.1 HBuilderX 可视化打包路线

用 HBuilderX 打包是大多数人的选择，操作门槛低。流程是这样的：

1. 在 HBuilderX 中打开 uniapp 项目。
2. 检查manifest.json的mp-weixin配置，重点确认 AppID 和插件配置。
3. 点击菜单栏“运行 - 运行到小程序模拟器 - 微信开发者工具”。
4. 如果你是第一次运行，HBuilderX 会要求配置微信开发者工具的安装路径，填上微信开发者工具的可执行文件地址（macOS 下一般在/Applications/wechatwebdevtools.app）。
5. HBuilderX 编译完成后自动唤起微信开发者工具并打开编译产物。

这个流程里，第 3 步的“运行到小程序模拟器”其实只是开发调试。真正要产出可上传的包，得走“发行 - 小程序-微信”菜单。发行模式下编译器会做压缩处理，产物体积会比运行模式小不少，而且会读取manifest.json中的mp-weixin.appid写入project.config.json。

这里有一个细节特别值得留意：HBuilderX 的发行模式不会自动应用urlCheck: false，它会保持你在manifest.json里的原始配置。所以很多人在开发环境调试得好好的，一发行后发现接口请求全部被拦截，就是因为urlCheck被写死成了 false，但发行时又被微信后台的域名校验规则覆盖。说明一下，这不是 HBuilderX 的 bug，而是微信开发者工具自身的规则：真机预览和上传发布走的是微信后台配置，跟本地开发模式不同。

3.2 CLI 工程打包路线：适合 CI/CD 自动化

如果你的项目是用vue-cli创建的 uniapp 工程，打包命令就变成了纯命令行。这也是我一直推荐的方式，因为可自动化、可重复执行，对团队协作友好。

项目根目录执行：

npm install npm run build:mp-weixin

这会在dist/build/mp-weixin下生成完整产物。如果只是想本地调试并让微信开发者工具自动刷新，用：

npm run dev:mp-weixin

CLI 模式下，vue.config.js里的配置会影响打包结果。比如常见的需要关闭eslint在 build 时报错阻断，可以这样配置：

module.exports = { lintOnSave: false, transpileDependencies: true, parallel: true }

parallel这个参数尤其重要。它控制是否让thread-loader开启多线程构建项目，小项目开启反而变慢，大项目不开则打包极慢。我实测过一个十几个页面的项目，开启之后构建时间从 40 秒降到 18 秒，效果显著。

CLI 路线唯一的痛点在于，修改manifest.json里的mp-weixin配置后，需要重新执行打包命令才会生效，不像 HBuilderX 那样保存即编译。所以 CI 脚本里每次打包前都要重新npm run build:mp-weixin，不要复用旧的 dist 目录。

3.3 打包前必查清单

一个几十页的小程序，发布出去发现白屏或者功能异常，大多是下面几个问题之一。我把自己的检查清单贴在下面，每次发版前过一遍：

• [ ]manifest.json里的mp-weixin.appid是否与微信公众平台一致
• [ ] 原生插件是否已在微信公众平台的“插件管理”中添加，且版本号与manifest.json中所填一致
• [ ] 接口域名是否已在微信公众平台“开发管理-服务器域名”中配置，或开发模式urlCheck为 false
• [ ] 主包体积是否超过 2 MB，若超限则检查是否有组件可转移到分包
• [ ] 微信开发者工具的基础库版本是否满足项目所有 API 的最低要求
• [ ]pages.json里是否有页面的navigationStyle设为custom，如果有，需要自行处理顶部导航栏高度

第六点我在实际项目中吃过亏。navigationStyle: custom模式下微信小程序不渲染导航栏，这时候你需要自己计算状态栏高度和胶囊按钮的位置来布局，不然自定义的导航栏会顶到状态栏或者把胶囊按钮盖住。

4. Webpack 构建优化与分包配置

4.1 构建性能优化的三个参数

uniapp 打包微信小程序底层走的就是 Webpack（HBuilderX 内置了定制版 cli 工具）。打包性能和产物质量，在vue.config.js里可以做出不少优化。我目前的配置是这样：

const path = require('path') module.exports = { lintOnSave: false, productionSourceMap: false, transpileDependencies: ['uview-plus'], parallel: true, configureWebpack: { performance: { hints: false }, optimization: { minimize: true, splitChunks: { chunks: 'all', minSize: 10000, maxSize: 250000 } } } }

这里有几个关键点：

productionSourceMap设为 false 非常关键。开启 sourceMap 会让产物体积暴涨，一个小程序的包可能因为一份.map文件多出 30% 体积。开发模式下 sourceMap 有助调试，发行模式下务必关闭。

transpileDependencies列表里加的依赖，表示这些包需要被 Babel 转译为 ES5。微信小程序的 JS 运行环境支持大部分 ES6 语法，但一些老的安卓机可能不支持。如果你引入了某个库，编译后发现在老设备上运行报错，大概率就是没转译，可以把它加进这个数组里。

splitChunks控制公共代码的抽取。uniapp 默认会对第三方库做代码分割，但这个策略容易产生一个超大的公共 chunk。我的做法是限制maxSize为 250 KB，强制 Webpack 把过大的 chunk 拆分，这样更有利于小程序的分包加载。

4.2 分包配置：主包瘦身与体积控制

微信小程序对包体积极其敏感。主包 2 MB、分包各 2 MB，总包不能超过 20 MB。而 uniapp 打包时有个特点：所有页面默认放进主包。这会导致一个几十页的项目很容易突破 2 MB 限制。解决方案是给页面做分包。

在pages.json中配置subPackages：

{ "pages": [ { "path": "pages/index/index", "style": { "navigationBarTitleText": "首页" } } ], "subPackages": [ { "root": "pages/sub", "pages": [ { "path": "detail/detail", "style": { "navigationBarTitleText": "详情页" } }, { "path": "user/user", "style": { "navigationBarTitleText": "个人中心" } } ] } ] }

分包的核心思想是：启动时用不到的页面尽量移进subPackages。比如详情页、支付结果页、用户协议页这些低频页面，放在分包里，主包只保留 tabBar 和首屏页面。

分包有个坑需要留意：subPackages里每个子包的页面路径是相对于该root目录的。比如root: "pages/sub"，那么页面路径detail/detail最终指向的物理路径是pages/sub/detail/detail.vue。如果你在pages.json的subPackages里写错了路径，编译不会报错，但运行时会提示页面不存在。

另外，uniapp 的分包里，组件之间互相引用如果跨包，会提示“找不到模块”。我一个项目里遇到过主包页面引用了分包里的组件，结果是页面可以加载，但组件渲染不出来，控制台只是报了一条usingComponents报错。排查了很久才发现是跨包引用的问题。经验是：公共组件必须放在主包或分包根目录下独立成包。

4.3 组件按需加载与体积压缩

有些 UI 库，比如 uview-plus，会提供按需引入的机制。你要在入口文件main.js里只注册用到的组件，而不是use整个库：

import { Button, Cell, Icon } from 'uview-plus' Vue.use(Button) Vue.use(Cell) Vue.use(Icon)

这个习惯在小程序端非常重要。整库引入会让vendor.js的体积轻松突破 500 KB，而按需加载能控制在 200 KB 以内。我实测过同一个页面，按需 vs 整库，主包体积差了将近 800 KB，这对小程序来说基本就是生与死的差别。

图片资源的处理同样不可忽视。小程序不支持本地图片的懒加载，所有的static目录下的图片都会被打进包内。如果不加节制地放原图，体积分分钟爆炸。我的方案是：所有 banner、背景图全部丢到 CDN，本地static只放图标类的小图（建议单张小于 30 KB），其余一律用网络地址。

5. 高频场景实操：导航栏、登录手机号与自定义分享

5.1 顶部导航栏与胶囊按钮的高度适配

微信小程序的顶部导航栏比较特殊，它在 iPhone 上会有刘海屏的额外高度，在安卓上又有状态栏高度差异。如果你的页面用了自定义导航栏（navigationStyle: custom），就要自己计算“状态栏高度 + 导航栏高度”，再把内容往下推。

我用的是一套封装好的工具函数：

export function getNavBarInfo() { const windowInfo = uni.getWindowInfo() const menuButton = uni.getMenuButtonBoundingClientRect() const statusBarHeight = windowInfo.statusBarHeight const navBarHeight = (menuButton.top - statusBarHeight) * 2 + menuButton.height const menuButtonRight = windowInfo.windowWidth - menuButton.left const menuButtonWidth = menuButton.width return { statusBarHeight, navBarHeight, menuButtonRight, menuButtonWidth } }

这段代码的逻辑是利用uni.getMenuButtonBoundingClientRect()获取右上角胶囊按钮的位置信息，胶囊按钮顶部到状态栏底部的距离乘以 2 再加上胶囊自身高度，就是标准的微信导航栏高度。不同机型、不同基础库版本下，这个计算结果都能自适应。

在实际使用中，把这个计算结果同步到全局状态或storage，然后在自定义导航栏组件的样式中使用。还要注意一点，uni.getMenuButtonBoundingClientRect()只能在真机或开发者工具上调用，在 H5 端返回的数据是空的。所以自定义导航栏组件最好配合条件编译处理。

5.2 登录与手机号授权：新版基础库用动态 token 方案

微信小程序的登录，标准的 uniapp 写法是：

uni.login({ provider: 'weixin', success: async (loginRes) => { const code = loginRes.code // 把 code 发送到后端，后端拿 code 换 openid 和 session_key } })

这个组合是老牌做法，目前还能用。但真正容易踩坑的是获取手机号。老版本的做法是button的open-type="getPhoneNumber"，用户点击后返回encryptedData和iv，后端解密得到手机号。

新版本基础库（2.21.2 之后）推出了getPhoneNumber动态令牌方案：用户点击授权后，前端拿到的是一个code，后端需要用这个code调微信接口换取手机号。开发模式必须能区分你在用哪种方案，否则会上报密钥错乱的问题。

uniapp 里的写法大概这样：

<button open-type="getPhoneNumber" @getphonenumber="handleGetPhoneNumber"> 获取手机号 </button>

methods: { handleGetPhoneNumber(e) { if (e.detail.code) { // 动态令牌方案 sendCodeToBackend(e.detail.code) } else if (e.detail.encryptedData && e.detail.iv) { // 旧版加密解密方案 sendEncryptedDataToBackend(e.detail.encryptedData, e.detail.iv) } } }

这里有个实际项目里最常见的报错：获取手机号按钮在开发者工具里点着没反应。原因多半是基础库里该版本已经强制走动态令牌方案，但你没有在开发者工具里切到足够高的调试基础库。解决方案是：在微信开发者工具右上角切基础库到最新版，然后重新编译。另外注意，这个按钮必须在用户真实点击后才生效，不能程序化地模拟点击，否则会报getPhoneNumber:fail denied。

5.3 自定义分享：onShareAppMessage 与 onShareTimeline

uniap 页面分享到微信好友，原生写法是生命周期函数onShareAppMessage。在 uniapp 里写法和原生几乎一样：

export default { onShareAppMessage() { return { title: '你有一份超好用的技术总结待领取', path: '/pages/index/index?from=share', imageUrl: 'https://cdn.example.com/share.png' } } }

如果你设置了自定义导航栏，分享菜单依然可用，不用担心。但要注意，onShareAppMessage中path参数如果你忘了加页面路径前缀，分享出去的链接点开后只会进入小程序首页，不会跳转到你指定的页面。这里推荐统一加path: '/pages/xxx/xxx?param=value'的完整格式。

分享到朋友圈则需要单独的onShareTimeline：

onShareTimeline() { return { title: '技术文章分享', query: 'from=timeline' } }

这个函数只支持摘要标题和 query 参数，不支持自定义封面。如果你发现onShareTimeline没有生效，多半是小程序还没有开通“分享到朋友圈”功能，需要在微信公众平台后台申请；或者当前页面使用custom导航栏导致分享菜单异常，这时候在页面首次加载时调一次uni.showShareMenu({ menus: ['shareAppMessage', 'shareTimeline'] })就能解决。

分享功能还有一个易错点：在真机上分享出去的卡片，标题和图片必须经过微信服务器验签，如果imageUrl是本地相对路径，分享卡片会变成默认图标。所以分享图片一定要用网络 URL，并且域名要在白名单内。

6. 实战中遇到的坑与排查技巧

6.1 白屏问题：从基础库版本和插件配置两路排查

白屏是打包后最让人崩溃的事，代码在 HBuilderX 里运行正常，丢进开发者工具却什么都没有。我总结过一套排查优先级方案：

1. 打开开发者工具的“调试器-Console”，看有没有未捕获的报错。最常见的报错是TypeError: Cannot read property of undefined，这个多半是因为某个 API 只在真机上支持，开发者工具没实现；或者你的requirePlugin里的插件名没在manifest.json里注册。
2. 检查编译产物里app.json的插件配置是否存在。打开dist/build/mp-weixin/app.json，看plugins字段是否包含你配置的插件。如果没有，说明manifest的配置没被正确合并，回到第二步改配置再重新打包。
3. 在开发者工具右上角切“基础库版本”。兔子一样的老接口在新基础库里可能被废弃，导致页面报错白屏。切换基础库到新版本后问题往往迎刃而解。
4. 检查控制台是否出现Failed to load local resource这类资源加载失败的问题，这通常是因为baseUrl或图片路径写错，编译后找不到静态资源。

白屏里最隐蔽的问题是app.json缺少插件字段。有一次我明明在manifest.json里配了插件，但发行出来的包里完全没有，后来发现是因为 HBuilderX 编译时，manifest.json的mp-weixin.plugins节点需要写在最外层mp-weixin下，而不是写在mp-weixin.uniStatistics之类的子节点下。这类“配置没生效”的问题，强烈建议每次打包后都检查一下产物里的app.json，不要想当然。

6.2 webpack 构建报错与依赖版本冲突

CLI 工程最大的坑是依赖版本冲突。uniapp 2.x 和 3.x 的编译内核完全不同，你要是把@dcloudio/uni-app系列依赖从 2.x 升到 3.x，几乎必然报错。我经历过一次线上项目升级完成后，编译时直接抛Cannot find module '@dcloudio/uni-cli-shared'，排查后发现是依赖树里有多个不同大版本的 uni-app 包混在一起。

这种情况下，第一步先清空node_modules和package-lock.json：

rm -rf node_modules package-lock.json npm install

如果还不行，就检查package.json里的所有@dcloudio/*版本是否统一。uniapp 的每个核心包都必须保持同一个版本号，不能一个 3.0.0-3081223 一个 3.0.0-3070701。

另一个常见构建报错是webpack 版本与 vue 版本不匹配。uniapp 官方 CLI 模板会指定对应的 webpack 版本，不要自己随便升级 webpack 大版本。升级一时爽，但一系列 loader 都要跟着换，非常容易爆出隐藏问题。npm 依赖尽量锁死精确版本，别用^范围符号。

6.3 多账号与多环境切换的自动化经验

日常开发免不了要切换不同的小程序 AppID，比如开发版、体验版、正式版三个环境对应三个小程序账号。手动在manifest.json里改 AppID 特别烦，而且容易漏改。

我自己的方案是写一个简单的 Node 脚本在打包前替换 AppID：

// scripts/switch-env.js const fs = require('fs') const path = require('path') const manifestPath = path.resolve(__dirname, '../src/manifest.json') const env = process.argv[2] || 'dev' const apps = { dev: 'wx1111111111111111', test: 'wx2222222222222222', prod: 'wx3333333333333333' } const manifest = JSON.parse(fs.readFileSync(manifestPath, 'utf-8')) manifest['mp-weixin'].appid = apps[env] fs.writeFileSync(manifestPath, JSON.stringify(manifest, null, 2))

然后配合两个npm scripts：

{ "scripts": { "switch:dev": "node scripts/switch-env.js dev", "build:dev": "node scripts/switch-env.js dev && npm run build:mp-weixin" } }

这样发版流程就变成了：先跑npm run switch:dev切换环境，再npm run build:mp-weixin。自动化之后，多个团队成员各自打各自的包，不会再出现“打出来的是别人环境的包”这种低级问题了。

顺带一提，多账号轮换还要注意微信开发者工具的登录态。如果你在同一个开发者工具里切换过多个小程序账号，容易出现“登录态失效”或“upload 权限不足”。遇到这种问题，先退出开发者工具账号重新登录，再重新编译一次就正常了。

6.4 日志打印控制：去掉生产环境的 console.log

调试阶段在代码里打了一堆console.log，发版前不清理就会留在产物里。浪费性能不说，还会暴露业务逻辑。小程序端要彻底去掉生产环境的 log，不能只靠肉眼删代码，得靠条件编译或者构建插件。

我一直在用的方案是定义一个统一的logger工具：

// utils/logger.js const isProd = process.env.NODE_ENV === 'production' const logger = { log: (...args) => { if (!isProd) console.log(...args) }, warn: (...args) => { if (!isProd) console.warn(...args) }, error: (...args) => { console.error(...args) } } export default logger

error级别保留，因为生产环境也需要错误输出以便排查线上问题；log和warn在构建时会被 webpack 的DefinePlugin替换成空逻辑。这样既不污染代码，又能灵活控制。

如果你不想用这种方案，也可以借助 webpack 的terser压缩配置自动去除 console。在vue.config.js里添加：

configureWebpack: { optimization: { minimizer: [ new TerserPlugin({ terserOptions: { compress: { drop_console: true } } }) ] } }

这个方案效果最简单粗暴，一行配置把生产包里的 console 全去掉。但注意，它会把console.error也一并干掉了，所以如果你确实依赖生产环境的 error 日志，就别用这个方案，用上面的 logger 方式更稳妥。

6.5 运行时兼容性：老机型、基础库与小程序防抖

微信小程序有个典型的兼容性矛盾：基础库版本越新，能用的 API 越丰富、性能越好，但用户端的老版本基础库会由于无法解析新特性导致白屏或功能失效。虽然微信会自动推送基础库升级，但总有用户停留在老版本。

我在项目里常用的策略是给首页加一个基础库版本判断：

const version = uni.getSystemInfoSync().SDKVersion function canUseDynamicPhone() { return compareVersion(version, '2.21.2') >= 0 }

compareVersion是一个版本号字符串比较函数，具体实现网上能找到很多，逻辑就是把版本号按点分隔、转数字逐一比较。这种兼容性处理一旦用上，后续迭代新增的 API 就不会脆弱地依赖“所有用户都是最新基础库”这个假设了。

控件交互上也要注意。微信小程序老版本对button内嵌view的点击事件穿透有兼容问题，一旦你的授权按钮和自定义弹窗叠在一起，点击授权按钮时会连弹窗关闭逻辑一起触发。解决方法是：不要用catchtap阻止冒泡，而是统一用tap事件，然后在逻辑里判断点击区域。这个经验是用一次线上 bug 换来的，当时用户在真机上点击授权，弹窗自动关闭，搞得用户一脸懵。

最后的实操心得

写到这里，再回头看看 uniapp 打包微信小程序这条路，核心其实就是三个环节：编译配置、插件接入、体积与兼容性控制。配置层面多看manifest.json和产物里的app.json，插件层面理清三种形态的区别，体积层面该分包就分包、该压缩就压缩。踩过的坑里，最值得说的还是那句老话：任何配置改动都不要想当然，编译完先看一眼产物里的app.json，很多白屏和插件不生效的根源都在那个文件里。

如果你现在正被某个打包问题卡住，我的建议是先把问题分成“配置层、编译层、运行层”三层逐层排查，不要一上来就怀疑 uniapp 的编译能力。绝大多数问题都是配置层的小事，花十分钟看一遍manifest.json和对应的产物文件，往往比在开发者工具里反复点“编译”有效率得多。希望这些实操经验能让你少走几个弯路。