响应式设计需将@media与语义化类选择器结合，按组件拆分断点样式，避免依赖DOM结构、伪类或属性选择器；断点值应基于实测设备宽度，交互态需适配触控场景。
用媒体查询配合类选择器控制组件样式
响应式设计不是靠单一选择器实现的，而是把 @media 规则和已有 CSS 类组合使用。比如你写了一个按钮组件 .btn，在桌面端是宽 200px、圆角 8px，到了移动端就得变窄、字体加大、圆角更明显——这些不能靠改 .btn 本身，得用媒体查询重新定义它的行为。
常见错误是把所有断点样式都堆在同一个 @media 块里，结果维护时找不到某条规则在哪。建议按组件拆分，每个组件的响应式逻辑尽量聚在一起：
@media (max-width: 768px) {
.btn {
width: 100%;
padding: 12px 16px;
font-size: 16px;
border-radius: 12px;
}
.header-nav {
flex-direction: column;
}
}
注意：断点值（如 768px）不是魔法数字，它应对应你实际测试过的设备宽度，而不是照搬 Bootstrap 的 sm 或 md 命名。
避免用元素选择器做响应式判断
写 立即学习“前端免费学习笔记（深入）”； 这样媒体查询只需改类的行为，不依赖结构层级。否则你改 HTML 的同时，还得同步翻查所有 这段代码在 iPhone 上基本不会触发 别指望纯 CSS 能覆盖所有交互路径，尤其当屏幕尺寸和输入方式同时变化时。 用 更稳妥的方式是用 class 控制状态： 然后由 JS 根据 真正难的不是写多少媒体查询，而是让选择器足够稳定、不随 DOM 深度或 JS 状态漂移。一旦选择器开始依赖运行时生成的属性或动态插入的节点，响应式就从样式问题变成了协作问题。nav ul li a { ... } 然后在媒体查询里再覆盖它，等于给自己埋坑。一旦 DOM 结构微调（比如加了个
.nav-item 替代 nav ul li
.card-header 替代 .card > h3
.grid-col-3 替代依赖 div:nth-child(3) 的布局逻辑@media 块里的选择器是否还生效。伪类与响应式交互的冲突点
:hover 在触摸设备上表现不可靠，:focus 在 iOS Safari 上常被忽略，而 :active 又可能因点击延迟导致视觉反馈错位。如果你写了：.btn:hover {
background-color: #0056b3;
}
@media (max-width: 480px) {
.btn:hover {
background-color: #004494;
}
}
:hover，所以第二段媒体查询毫无意义。真实做法是：
:focus-visible 替代部分 :focus 场景@media (hover: none) 单独处理交互态.is-pressed 类来模拟 :active
属性选择器在响应式中的隐蔽风险
[data-breakpoint="mobile"] 这类属性选择器做响应式控制看似灵活，但容易引发两个问题：一是 JS 动态切换属性时，CSS 重绘不及时；二是服务端渲染（SSR）和客户端 hydrate 不一致，导致首屏样式闪动。html[data-device="mobile"] .sidebar {
display: none;
}
html[data-device="desktop"] .sidebar {
display: block;
}
window.matchMedia 结果给 加或删 data-device 属性。注意：不要监听 resize 频繁修改，用 matchMedia().addEventListener 更精准，也避免抖动。
