小程序兼容性测试，别等上线才踩坑

上周帮朋友收拾一个烂摊子：一个上线两周的小程序，iOS 上好好的，安卓上一进商品详情页就白屏。查了半天，是某个机型上 position: sticky 配合自定义导航栏出了问题。这类事我见得太多，今天就把小程序兼容性测试这块的经验捋一捋，都是踩过的坑。

为什么小程序兼容性比 H5 更麻烦

很多人觉得小程序跑在微信里，环境统一，应该比 H5 省心。理论上没错，但实际情况是：

• 基础库版本分散。用户手机上的微信版本参差不齐，老版本基础库缺 API 是常事。
• 渲染引擎双轨。iOS 用 WKWebView，安卓部分场景走 X5 内核，CSS 表现会有差异。
• 机型碎片化。尤其安卓，屏幕比例、刘海、字体缩放、深色模式，组合起来能出几十种情况。
• 系统能力差异。定位、蓝牙、相册权限这些，不同系统版本的行为完全不同。

所以别指望“我本地跑通了”就万事大吉，兼容性测试必须当成一个独立环节来做。

先定测试范围，别盲目铺开

全机型全覆盖不现实，也没必要。我的做法是先看后台数据，按用户占比排序：

1. iOS 取最新两个大版本，覆盖主流 iPhone 尺寸（小屏 SE、标准、Pro Max 各一台）。
2. 安卓取用户量前五的品牌，重点看华为、小米、OPPO、vivo，再补一台低端机（内存 4G 以下）。
3. 基础库版本，至少测最低支持版本和当前最新版本两档。

真机不够就用云真机平台，按次付费比买设备划算。但要注意，云真机测不了传感器和蓝牙，涉及这些功能还是得借真机。

几个最容易翻车的点

1. 自定义导航栏与安全区

刘海屏、挖孔屏的顶部安全区处理不好，标题就被挡住。用 wx.getSystemInfoSync() 拿 statusBarHeight 和胶囊按钮位置来算，别写死数值。

const sys = wx.getSystemInfoSync()
const menu = wx.getMenuButtonBoundingClientRect()
// 导航栏高度 = 胶囊底部到状态栏底部的距离 + 上下留白
const navHeight = menu.bottom + (menu.top - sys.statusBarHeight)

底部同理，iPhone 有 Home Indicator，safeArea 字段要用上，固定定位的按钮别贴着底边。

2. 字体缩放

安卓系统设置里能调字体大小，用户调大之后，你写死高度的容器直接文字溢出。要么用 rpx 配合弹性布局，要么在 app.json 里关掉页面字体缩放。这个坑很隐蔽，测试时记得手动去系统设置里把字体调到最大试一遍。

3. 深色模式

微信支持跟随系统深色模式，如果你的页面有硬编码的白色背景，晚上打开就是一片刺眼。要么全局适配，要么在配置里锁定浅色，别半吊子。

4. 图片与长列表

低端安卓机上，大图列表滚动卡顿非常明显。测试时重点看首屏加载时间和快速滑动时的掉帧情况。图片统一走 CDN 压缩，长列表用 recycle-view 或者分页加载，别一次性渲染几百条。

5. 授权与权限

相册、位置、麦克风，用户拒绝一次之后的二次唤起逻辑，各机型表现不一。iOS 拒绝后需要引导去设置页，安卓部分机型会直接静默失败。这块一定要在真机上把“拒绝—再次请求—去设置开启”整条链路走完。

把测试变成流程，而不是救火

我的习惯是提测前先跑一轮自动化冒烟：用 miniprogram-automator 把核心页面的跳转、下单流程跑一遍，能挡住大部分低级错误。然后人工重点测上面列的五个高危点。上线前再拿最低基础库版本过一遍，确认没有用到新 API 却没做降级。

兼容性问题有个特点：发现得越晚，修起来越贵。上线后用户反馈白屏，你连复现都难，只能靠日志猜。所以宁可多花半天时间在真机上点一点。

说到底，小程序兼容性测试不是技术难题，是耐心活。把测试机型清单固定下来，每次发版照着过一遍，比什么工具都靠谱。工具能帮你省时间，但替代不了你在那台卡顿的老安卓上亲手滑两下的直觉。