按F12打开开发者工具并进入响应式模式，手动输入典型宽度（如375px、768px）验证断点触发时布局是否真正重组，重点检查导航折叠、图片重排、文字换行，并开启rulers确认视口尺寸，右键检查元素核实生效规则是否来自预期媒体查询。
用浏览器开发者工具快速验证断点是否生效
真机测试前，先在 Chrome 或 Edge 里按 F12 打开开发者工具，点设备切换图标进入响应式模式。重点不是“能不能缩放”，而是看关键断点（比如 768px、1024px）触发时，布局是否真正重组——导航栏是否折叠、图片是否重排、文字是否换行合理。
常见错误现象：拖动窗口边缘时布局“卡住”不动，或只在某个像素值附近反复抖动。这往往说明媒体查询写成了 @media (max-width: 768px) 和 @media (min-width: 768px) 重叠，漏掉了等于号的边界处理。
实操建议：
- 手动输入几个典型宽度（如
375px、414px、768px、1200px），不要只依赖预设设备 - 勾选“Show rulers”查看实际视口尺寸，避免被缩放或地址栏高度干扰
- 右键检查元素，确认当前生效的 CSS 规则是否来自预期的媒体查询块
真实设备上必须测横竖屏切换和触摸反馈
模拟器看不出按钮是否够大、滑动是否跟手、菜单是否能顺畅展开。尤其要注意触控目标（button、a、表单控件）的物理尺寸——iOS 要求不小于 44px × 44px，Android 建议 ≥ 48dp。
立即学习“前端免费学习笔记（深入）”；
性能影响容易被忽略：在低端安卓机上，用 transform: scale() 实现的缩放动画可能掉帧，而纯 width + height 变化更稳；但后者又可能引发重排（reflow），拖慢渲染。
实操建议：
- 用局域网 IP（如
http://192.168.1.100:3000）让手机直连本地开发服务器，避免代理或压缩干扰 - 横竖屏切换后，检查固定定位元素（如底部导航）是否错位——
position: fixed在 iOS Safari 中对vh单位支持不稳定 - 点击按钮后观察是否有视觉反馈（如
:active状态变色），没有的话用户会怀疑没点中
检查 CSS 是否真正“弹性”，而非表面响应
很多页面只是加了媒体查询，但核心结构仍是固定像素宽度，导致小屏上内容溢出或留大片空白。真正的弹性体现在三处：max-width: 100% 的图片、用 rem 或 em 定义的字体、以及基于 flex 或 grid 的容器。
容易踩的坑：
-
img { width: 100%; height: auto; }忘了加max-width: 100%，当父容器有 padding 时仍会撑破 - 用
px写 margin/padding，小屏下留白过大，应改用rem并配合根字体缩放 - Flex 容器内子项用了
white-space: nowrap，导致文本无法换行，横向滚动出现
可快速验证：在开发者工具中临时禁用所有 @media 规则，只留基础样式，看页面是否还能基本可用——如果直接崩坏，说明基础流式结构没立住。
z-index 层叠问题在移动端最容易暴露
桌面端看着正常的导航栏、弹窗、悬浮按钮，在手机上突然被轮播图或 banner 遮住，八成是 z-index 层叠上下文断裂。根本原因不是数值不够大，而是某个父容器意外创建了新的层叠上下文（比如加了 opacity: 0.99、transform、will-change），导致子元素的 z-index 只在该上下文内有效。
实操建议：
- 给所有固定定位元素（
position: fixed）显式设置z-index，哪怕只是z-index: 10 - 避免在父级上滥用
transform或opacity，除非明确需要隔离层叠 - 用开发者工具的“Layers”面板（Chrome）查看实际渲染层，确认关键 UI 元素是否处于顶层
最麻烦的情况是：你调高了按钮的 z-index，但它依然被遮住——这时候得往上查三层父元素，看哪个悄悄创建了新层叠上下文。
