移动端优化

为什么需要这个检查

移动端页面最常见的 bug 往往不在 JS 逻辑里，而在 HTML 头部和内联样式里：viewport 缺失导致布局按桌面宽度渲染，width: 700px 的容器在 360dp 屏幕上直接触发横向滚动，font-size: 12px 让正文在高 DPR 屏上糊成一团，按钮点击区域过小导致误触。这些在桌面端预览时很难发现，只有真机或移动模拟器里才会暴露，而且是逐个元素肉眼排查，非常耗时。

技能如何工作

这个技能把「移动端友好性检查」拆成几项静态扫描，对页面逐条打分：

• Viewport meta tag：检查标签是否存在、是否带 width=device-width、是否设置了 user-scalable=no 或 maximum-scale=1（会损害无障碍）。
• Fixed-width elements：扫描所有带内联 style 的元素，找出 width 超过 500px 的，给出违规元素数量。
• Font sizes：检查内联 font-size 值，标记过小字号。
• Touch targets：检查可点击元素的尺寸是否达到触控目标要求。
• Media queries：确认是否存在针对移动端的媒体查询样式表。
• Tables：如果页面超过 2 个 <table>，提示表格在手机上难以阅读，建议改用响应式表格模式。

每条结果带状态标记：❌ FAIL（直接判失败）、⚠️ WARN（风险提示并说明原因）、✅ PASS（配置正确）。

适用边界与注意点

• 如果页面没有任何内联样式，fixed-width 和 font-size 检查会被跳过——静态 HTML 检查看不到运行时注入的样式。
• CSS-in-JS 框架（如 styled-components、Emotion）在运行时才生成样式，仅靠静态 HTML 无法审计，技能会注明这个限制。
• display: none 或 visibility: hidden 的元素会被排除在触控目标检查之外。
• AMP 页面有自己的 viewport 规则，检测到 AMP 样板代码时只标记、不判失败。
• PWA 启动屏和应用壳层可能有意设置 user-scalable=no，此时仍给 WARN 但会注明上下文。

换句话说，这是一个快速、确定性的静态审计，适合放进 CI 做提交前检查或代码评审参考，而不是替代真机测试。