你的移动端页面明明能打开，为什么用户还是走了？
你有没有试过：凌晨改完代码，用 Chrome 模拟器看一遍，完美；早上上线，后台跳出率突然飙高，用户平均停留不到10秒就关掉——连个错误提示都没有。
不是内容不行，也不是加载太慢。问题藏在“看起来正常”的缝隙里：那些真机上才露馅的适配异常。
为什么你的“响应式”在真机上像个残废？
用了 Bootstrap，写了 @media，不等于移动端就稳了。
我帮一个做母婴电商的朋友排查过：PC端加购转化一直稳定，移动端总卡在最后一步。折腾半个多月，最后发现是某个客服插件在 iOS 上悄悄触发了一个 display: none 的弹窗，但这个弹窗被撑到了屏幕外侧。用户每次点“立即购买”，焦点都被它劫走——表单没提交，按钮没反馈，页面也没跳转。人眼看不见，但浏览器全认。
还有字体缩放这事。你设了 font-size: 14px，觉得刚刚好。可用户在微信里双击图片想放大看细节，整个页面文字跟着一起放大，布局瞬间错位。这不是 bug，是 text-size-adjust 默认开着。你没关，它就敢动你的排版。
具体检查方法：别只信 Chrome DevTools 的模拟器。它再像，也模拟不出安卓旧机型的系统字体、iOS 的 WebKit 渲染差异、微信/QQ 内置浏览器的私有内核。我手机相册里常年存着两台“测试机”：一台 2017 款 iPhone SE（iOS 15），一台红米 Note 7（Android 11）。新功能上线前，先在这俩机器上跑三遍。
触控反馈延迟：这3个细节让你流失了80%的用户
手指和鼠标，根本不是一回事。
PC 上 hover 能悬停，移动端一碰就得有反应。可很多人直接把 PC 的 :hover 样式搬过去——用户点按钮，没变化；再点，还是没变化。他不会等，他会划走。
300ms 延迟这事，现在大部分场景确实没了。但如果你页面里用了 touchstart 却没配 touch-action: manipulation，或者 CSS 动画太重，延迟照样回来。用户点一下，等半拍才有反馈，第一反应就是“卡了”。
还有点击区域。PC 上 10px 的关闭按钮都能点中，移动端手指最小触控面积是 44×44px。你那个 20px 高的 × 按钮，用户戳十次，能点中两次算运气好。
真实案例：一个本地生活资讯站，用户刷着刷着就退出。我抓了他们列表页的 DOM，发现每条新闻只在标题文字上绑了点击事件，标题下面大片空白区域完全不响应。用户想点下一条，手指偏一点，就点到上一条去了。我们把整个列表项 <li> 设为可点击区域，用户停留时长明显提升。
你的图片和字体，正在谋杀用户的流量和电池
WiFi 下测得再顺，也不代表用户能忍。
地铁里信号断续，4G 切换中，用户点开你的首页，等三秒，没动静，直接切走。你那张 3MB 的 Banner 图，在 PC 上可能 2 秒就出来，在弱网下可能要 10 秒以上。
srcset 和 <picture> 不是贴了就灵。如果 sizes 属性写错了，浏览器根本看不懂你想要多大尺寸的图。我见过一个活动页，只显示一个 32×32 的小图标，结果因为 sizes="100vw"，浏览器硬是拉了一张 2000px 宽的原图下来——用户每刷一次，就多耗几 MB 流量。
字体更麻烦。你选了个好看的自定义字体，PC 上加载顺利。移动端呢？字体文件加载失败，用户看到的是方块或宋体；更糟的是，如果 @font-face 没配 font-display: swap，页面会白屏等字，等上好几秒。
具体做法：图片统一转 WebP，用 <picture> 包一层，兜底用 JPEG；字体必须加 font-display: swap，让内容先出来，字体后替换。别让用户对着白屏发呆。
滚动卡顿和页面抖动：用户以为你网站有毒
手指一滑，页面卡成幻灯片？用户不会想“是不是网络不好”，他会想“这网站怎么这么卡”。
最常见的两个坑：position: fixed 和渲染层爆炸。
固定定位在移动端特别吃性能。滚动时，浏览器要反复计算它的位置。如果这个元素还带阴影、圆角、透明度动画……每次滑动都在重绘。有些安卓机甚至会让 fixed 元素在滚动中闪一下。
另一个是“小动画堆成山”。你只加了一个旋转的 loading 图标，但它没加 will-change: transform 或者 transform: translateZ(0)，浏览器就给它单独建一个渲染层。页面里十几个这样的小动画，渲染层数量直接爆表，GPU 跟不上，滑动就卡。
检查方法：用 Chrome 真机调试（USB 连接手机），打开 Performance 面板，录一段手动滚动操作。看帧率曲线，掉到 30fps 以下，用户就能明显感觉到卡。我之前帮一个社区产品优化，发现是第三方广告脚本在 scroll 里疯狂查 DOM，删掉后，滑动顺了不止一倍。
表单提交失败：你永远不知道用户输了多少次
这是转化漏斗的最后一道门，也是最容易被忽略的雷区。
用户填完手机号、验证码、收货地址，点“提交”，页面没反应。他再点一次，还是没反应。他以为网络断了，退出重进，重新填一遍……第三次终于成功，后台却收到三条重复订单。
原因很实在：
- 提交按钮没
:active状态，用户点下去不知道有没有生效； - 错误提示用 tooltip 弹在键盘上方，键盘一弹出，提示就被盖住；
- 输入手机号的
input没设type="tel"，弹出的是全键盘，用户输完还得手动切数字键盘输验证码。
真实案例：一个旅游预订站，提交后跳转新页面。但移动端跳转有延迟，用户以为没点上，连点三次。我们改成：点击后按钮立刻变灰 + 显示“提交中…” + 同时禁用按钮。改完当天，重复提交订单数就大幅下降。
今天就能执行的1个操作：在真机上跑一遍“用户旅程”
别翻数据报表了。
现在，就拿出你手边最常用的那台手机（不是模拟器），打开你自己的网站，按顺序走完这五步：
- 打开首页，等它完全加载完
- 点进任意一篇文章/商品详情
- 尝试加入购物车或收藏
- 找到注册/下单表单，填一条真实信息（用测试手机号）
- 点击提交，看到成功提示为止
过程中留意：
- 页面加载有没有明显等待？
- 点按钮有没有视觉反馈（颜色变、加 loading、变灰）？
- 滚动是否跟手？有没有突然卡顿或抖动？
- 键盘弹出后，输入框和错误提示还在不在视野里？
- 提交后有没有明确的状态反馈？
把你遇到的每一个“咦？这里不对”截图存下来，标上序号。明天开工，就从第一个问题开始修——比如，如果表单按钮点了没反应，那就先加上 :active 样式和防重复点击逻辑。一个小动作，可能就拦住了今天一半想离开的人。