真机测试实战：从环境搭建到常见问题排查技巧

又踩坑了，真机上滚动卡成PPT

上周改一个移动端的弹窗组件，本地 Chrome DevTools 里跑得飞起，手势滑动、滚动都丝滑得很。结果一丢到 iPhone 上真机测试，直接卡成幻灯片——手指划一下，页面要愣半秒才动，再划一下，又卡住。用户要是看到这效果，怕不是以为手机坏了。

我第一反应是：是不是我写了什么性能差的代码？赶紧把 touchmove 事件监听器里的逻辑翻出来看，结果就几行简单的 scrollTop 赋值，连复杂计算都没有。本地模拟器也没问题啊，怎么一到真机就崩？

折腾了半天，发现是 passive 的锅

查了一圈资料，想起 iOS Safari 对 touchmove 和 touchstart 默认启用了 passive 模式。啥意思？就是浏览器默认认为你不会在 touch 事件里调用 preventDefault()，所以它提前开始滚动，不等 JS 执行完。但如果你偏偏在 touchmove 里写了 e.preventDefault() 来阻止默认滚动（比如做自定义下拉刷新），那浏览器就会卡住——因为它已经提前滚了，现在又要“撤销”这个动作，性能直接爆炸。

更坑的是，Chrome DevTools 的设备模拟模式默认不启用 passive 行为，所以你在电脑上永远测不出这个问题！只有真机或者开启特定 flag 的浏览器才会暴露。我之前一直以为是自己逻辑写错了，结果白折腾两小时。

验证方法很简单：在真机 Safari 里打开控制台（通过 Mac 的 Web Inspector 连 iPhone），然后触发滚动，如果看到类似这样的警告：

[Intervention] Unable to preventDefault inside passive event listener due to target being treated as passive.

那基本就是这个问题没跑了。

三种方案对比，我选了最简单的

解决办法其实就几种：

• 方案一：给 addEventListener 显式传 { passive: false }，告诉浏览器“我可能会阻止默认行为，别提前滚”
• 方案二：重构逻辑，避免在 touchmove 里调用 preventDefault()，改用 CSS 属性如 overscroll-behavior 或 touch-action 控制滚动
• 方案三：用 wheel 事件替代（但移动端 wheel 支持不好，基本不用考虑）

我一开始想试试方案二，毕竟 passive 是未来趋势，能不用 preventDefault() 最好。但项目里有个自定义的侧滑菜单，必须在 touchmove 中动态计算偏移并阻止页面滚动，CSS 方案搞不定。那就只能回退到方案一。

不过这里有个大坑：如果你用的是 Vue、React 这类框架，它们的事件系统会自动处理 passive，你直接写 @touchmove="handler" 可能还是会默认 passive。得手动用原生方式绑定。

核心代码就这几行

最后我的解决方案是：对需要阻止默认滚动的元素，手动添加带 { passive: false } 的事件监听器，并在组件销毁时移除。

以下是一个简化版的可复用 hook（用原生 JS 写的，方便理解）：

function useCustomScroll(element, onMove) {
  let startY = 0;
  let currentY = 0;

  const handleTouchStart = (e) => {
    startY = e.touches[0].clientY;
  };

  const handleTouchMove = (e) => {
    currentY = e.touches[0].clientY;
    const deltaY = currentY - startY;

    // 假设我们只在特定条件下阻止滚动，比如内容还没到顶/底
    if (shouldPreventDefault(deltaY)) {
      e.preventDefault(); // 这行在 passive: true 下会无效甚至报错
    }

    onMove && onMove(deltaY);
  };

  // 关键：passive 设为 false
  element.addEventListener('touchstart', handleTouchStart, { passive: true });
  element.addEventListener('touchmove', handleTouchMove, { passive: false });

  // 返回清理函数
  return () => {
    element.removeEventListener('touchstart', handleTouchStart);
    element.removeEventListener('touchmove', handleTouchMove);
  };
}

// 示例使用
const el = document.querySelector('.custom-scroll-area');
const cleanup = useCustomScroll(el, (delta) => {
  console.log('滑动距离:', delta);
});

// 组件卸载时调用 cleanup()

注意：touchstart 我还是设为 passive: true，因为一般不需要在 start 阶段阻止默认行为，这样能保持启动速度。只有 touchmove 需要设为 false。

另外，shouldPreventDefault 这个函数很重要——别无脑 preventDefault()。比如你的内容区域已经可以滚动了，那就别拦着，让用户正常滚。只有在边界（比如顶部还想下拉）才阻止。否则整个页面都会变得“粘手”，体验更差。

function shouldPreventDefault(deltaY, container) {
  const scrollTop = container.scrollTop;
  const scrollHeight = container.scrollHeight;
  const clientHeight = container.clientHeight;

  // 下拉（deltaY > 0 表示手指向下划）
  if (deltaY > 0 && scrollTop === 0) {
    return true; // 在顶部还想下拉，阻止默认
  }
  // 上拉（deltaY < 0 表示手指向上划）
  if (deltaY < 0 && scrollTop + clientHeight >= scrollHeight) {
    return true; // 在底部还想上拉，阻止默认
  }
  return false;
}

踩坑提醒：这三点一定注意

1. 别在所有 touchmove 上都关 passive。只有确实需要 preventDefault() 的地方才关。否则会影响整体滚动性能，尤其是长列表。

2. iOS 13+ 和 Android Chrome 行为还不完全一致。Android 上有时候即使 passive 为 true，preventDefault() 也不会报错（只是无效），但 iOS 会直接警告甚至卡顿。所以测试一定要覆盖多个真机。

3. 框架用户特别小心。Vue 3 的 @touchmove.passive="handler" 是开启 passive，而 @touchmove="handler" 默认其实是 passive（出于性能优化）。如果你想关掉 passive，得用 $el.addEventListener 手动绑。React 也是类似，合成事件默认 passive。

改完还有个小问题，但无大碍

上线后发现，在极低端安卓机上（比如 2GB 内存的老机型），快速连续滑动时偶尔还会有一帧卡顿。但比起之前的“完全不动”，已经是天壤之别。考虑到用户占比不到 0.5%，而且不影响核心功能，我就没继续深挖。可能跟主线程被其他任务阻塞有关，属于另一个层面的优化了。

总之，这次教训就是：**移动端开发，真机测试不能省**。模拟器再像，也模拟不出浏览器内核的真实调度策略。尤其是涉及手势、滚动、动画这些和底层交互紧密的功能，不插真机等于没测。

以上是我踩坑后的总结，如果你有更好的方案欢迎评论区交流。比如有没有办法用 CSS 完全绕过 JS 阻止滚动？或者现代框架里更优雅的 passive 控制方式？我都想听听。