“快帮我看下线上版本怎么回事，首页白屏了。” 周五晚上十点半，同事在群里紧急呼叫。我打开后台，发现三天前提交审核的一个小功能刚刚通过，而今天下午又改了一行css导致样式错乱。这已经是这个月第三次为了一个两行的bug去提交微信审核了。每次发版都要等两到三天，用户体验极差。后来我研究了一下uniapp的“热更新”机制，发现小程序端根本不需要整包发布，可以只更新掉那些修改过的js资源。琢磨了两天，我把项目里的自动更新模块重写了一遍，最终发版时间从两天压缩到了十分钟，而且再也没因为一个小改动让用户白屏。
先弄明白小程序热更新的本质
小程序不像App那样能直接下载新代码包，微信有自己的一套更新策略。你上传到微信后台的代码，经过审核通过后，用户需要重新打开小程序才会触发整包下载。如果你不做任何处理，用户在小程序停留很久，你修复了bug也只能等他冷启动才会加载新版本。更关键的是，微信限制主包大小不能超过2M，一旦开发时资源膨胀，想塞一个小功能都很困难。
uniapp官方提供了一套“热更新”方案，其实是通过uni-app的uni.requireNativePlugin或者plus.runtime.openURL等接口实现App的版本更新。对于小程序端，官方并没有直接提供“热更新接口”，但我们可以利用小程序本身的“分包加载”和“运行时动态替换”来实现一种类似热更新的效果。说白了，就是通过远程服务器下发最新代码片段，然后在小程序里动态执行或覆盖掉旧的页面逻辑。因为小程序不允许动态加载远程js，所以实际采用的变通方案是：把需要热更新的页面做成离线的“模板”，然后通过后端下发数据去改变页面显示，或者干脆使用web-view加载h5页面。
我的需求其实很简单：快速修复线上bug，无需等待审核
我们公司的小程序是一个工具类应用，底部五个tab，里面嵌套了很多二级页面。有个别页面功能很独立，比如“计算器”和“汇率查询”。这些页面不依赖原生SDK，纯粹是前端逻辑。我当时的想法是：如果某一个独立页面的逻辑写错了，能不能单独修复这一个页面，而不影响整个小程序？答案是能，但只能用最土的办法：用web-view把那个页面嵌一个H5。你问我为什么不用小程序原生页面？因为原生页面的任何修改都必须经过微信审核。而web-view里的H5放在自己的服务器上，随便改，秒生效，完全绕开了审核。
于是在新版本里，我就把几个经常需要改文案和计算规则的页面替换成了web-view。但问题来了，web-view加载的H5体验比不上原生页面，而且交互流畅度也差一点。这个方法虽然能“热更新”，但本质上是在用H5换原生。
一个更好的骚操作：使用小程序“本地代码包”+“动态路由”
如果你的改动不涉及到新增原生功能，只是修改某个组件或页面的JS逻辑，那你完全可以做“局部代码替换”。但这里的替换不是指你在小程序里远程加载一段js，而是指你在开发阶段就把需要频繁更新的部分拆成一个独立的分包，然后在发布时，只用覆盖这个分包的内容。然而微信并不支持运行中下载分包。
实际上，小程序官方提供的“分包异步化”允许你通过require.async提前加载分包，但不能替代主包代码。所以我们换了一种思路：经常要改的页面，做成一个空的壳子，壳子里面放置一个模板组件，模板组件的内容通过接口从服务器获取，并动态渲染。这样你修复一个显示bug，只需要在后端修改模板数据，前台就能立刻展现修复后的样式，不需要发版。
不过这种方式对交互逻辑复杂的页面就没什么用了，只能改改文字、颜色、图片之类的。
在我们项目里真正落地的方案：条件编译+多渠道部署
虽然上面的方法能解决一部分场景，但程序员怎么能放弃用代码解决代码问题？最后我们在uniapp项目里搞了一个真正意义上的“热更新”，它不需要改造成web-view，也不需要完全靠模板渲染，而是利用微信小程序的“开发环境不校验请求域名”和“真机调试”功能配合后端接口覆盖代码。说白一点：把整个页面的逻辑抽象成一个函数，这个函数通过后端接口动态下发。比如我们有一个“秒杀倒计时”组件，里面的时间计算逻辑之前写在前端，后来发现时间不准，我们接口返回一个时间偏移量，前端动态修正。这其实也是一种“数据热更新”。
但这依然不够“热”。后来我看到了一个偏门办法：由于uniapp编译后的小程序代码是一个个js文件，而微信小程序的代码包内容是可以在启动时通过wx.getUpdateManager监听并强制更新的。这虽然要重启小程序，但不用你去应用商店审核。比如你上线后发现了严重bug，可以通过后台配置一个“强制更新”标志，前端检测到后，调用wx.getUpdateManager立刻下载最新代码包并重启。这在本质上是整包更新，但不需要等待审核，因为微信允许你在审核通过后，随时发布“不涉及审核”的紧急修复？其实微信小程序并没有这种机制，所有代码更新都要过审。
但有一种特殊情况：开发者工具上传的“开发版”和“体验版”可以直接在手机上预览。所以很多团队为了避开审核，直接把正式版小程序做成一个空壳，里面所有页面都是用web-view加载H5，这样真正的业务代码都在H5服务器上，改的就是H5，与微信审核无关。
具体怎么实现：用一个配置文件控制远程更新
在我们项目里，最后我用了一个相对妥协但稳定的方式：把项目里不需要原生功能的一部分页面用web-view承载，H5页面放在自己的云服务器上。然后我在小程序端维护一个路由表，从接口读取一个路由配置文件，这个文件里写了哪个页面用原生，哪个页面用web-view。
// config.js
const remoteConfig = {
"pages": {
"pages/tools/calculator": {
"type": "webview",
"url": "https://yourcdn.com/h5/calculator.html?v=1.0.3"
},
"pages/tools/exchange": {
"type": "native"
}
}
}
// 在页面跳转时做判断
function navigateTo(url, params) {
const config = remoteConfig.pages[url];
if (config && config.type === 'webview') {
uni.navigateTo({
url: '/pages/webview/index?targetUrl=' + encodeURIComponent(config.url)
});
return;
}
// 否则走原生页面跳转
uni.navigateTo({ url });
}这样，当你改了H5页面，只需要把config里的版本号改一下（或者直接换URL），小程序就会加载最新的H5内容，完全绕开微信审核。而原生页面依然保留原有体验。
踩过的坑：webview页面和原生页面通信
把业务搬到H5后，最麻烦的是H5怎么调用原生能力，比如获取用户信息、付款等。我一开始用uni.webview.js在H5和uniapp原生之间搭桥。但发现用起来并不顺手，特别是在H5里要用vue-router时，路由跳转和uniapp的路由混在一起。后来我索性在H5里只用uni.request请求后端接口，把需要原生功能的部分封装成url参数。
// H5页面里的调用
function openPayment(orderId) {
// 通过postMessage告诉小程序
uni.postMessage({
data: {
action: 'pay',
orderId
}
});
}// 小程序端监听
const webviewContext = uni.createWebViewContext?.('webview-1');
wx.onMessage((event) => {
const data = event.data[0];
if (data.action === 'pay') {
// 调用小程序支付
uni.requestPayment({...});
}
});这个通信方案在小程序里还算稳定，但在安卓某些机型偶尔会丢消息。后来我直接把数据存在storage里，H5通过轮询去读，反而更可靠。虽然笨拙了点，但总比丢了支付数据好。
另一种更原生的“热更新”：使用微信小程序“小游戏”的代码包机制
你可能听过小游戏的“热更新”，因为小游戏没有审核，可以随时上传新代码。而普通小程序不行。但uniapp还支持编译到H5和App，如果是App端，就能用plus.runtime.update实现真正的资源热更新，就像React Native那样。可惜这题问的是小程序，所以我没细究App端。
不过话说回来，如果你想在小程序端实现真正的“代码热替换”，基本不可能。但你可以通过web-view和接口配置实现“业务热更新”。这就是目前业内最常用的一种做法。
最终的改造效果
改造后，我们页面里凡是不涉及原生功能的模块（比如汇率计算、BMI计算、文案展示），全部走webview。实际工作量比我预想的少。因为我们的这些页面本身逻辑简单，用vue写H5几乎就是复用原来的代码。然后我再写了一个发布脚本，每次修改H5就直接构建并上传到CDN，同时更新小程序内的一个远程映射表。现在改完一个bug，只需要跑一下脚本，小程序用户下次打开就会加载到最新的H5，虽然他们看到的还是原来的页面路径，但内容已经更新了。再也不用等微信审核了。
你可能想问的坑
- webview页面打开慢怎么办？ 做离线包缓存，把H5静态资源放到CDN，然后用H5的localStorage做数据缓存。第一次加载慢，之后会好很多。
- webview能覆盖原来页面的原生导航栏吗？ 可以。你在uniapp里用web-view时，原生导航栏是保留的，你可以在H5里再写一个顶部导航。但这样会有两层导航，不好看。我一般选择把导航栏透明化，让H5完全接管。
- 这等于放弃了微信小程序的原生体验？ 是的，但只针对特定模块。核心主流程还是原生页面，毕竟流畅度和交互更好。而一些不常用、改得勤的功能，用webview是最省事的。
- 审核会不会因为webview被拒？ 微信审核对webview的使用比较敏感，尤其涉及支付和虚拟内容。我们这些页面没有敏感操作，审核能过。如果你的H5里面有诱导分享或违规内容，很容易被拒。
一些其他的热更新思路（没实践但值得研究）
如果你不想用webview，推荐看一下“小程序分包异步化”。你可以把经常更新的页面放在一个独立分包里，然后在主包里用wx.require.async在运行时加载分包。但分包内容依然是审核时锁定的，不能单独更新。所以意义不大。
还有种方式是使用wxs文件，wxs不能调用接口，也没法做动态更新。别再想了。
最后说点实在的
如果你只是一个小团队，没有太多资源去搭复杂的更新系统，我的建议是：把业务按“稳定”和“易变”分类。稳定的页面继续用原生开发，易变的页面直接做webview。小程序的审核真的挺耗时，能不碰就不碰。我们这次改造帮团队节省了大量发版时间，也让运营能更快速地调整活动页面。虽然有些人会批评说“webview体验不好”，但在资源有限的情况下，这已经是成本最低的“热更新”方案了。
希望这篇文章能给你一些启发，让你下次遇到“改一行字还要等两天审核”的困境时，多一条路可以走。
