display: none配合媒体查询是最可靠方案，需显式设默认状态并按视口能力设断点；hidden属性不响应视口变化，visibility和opacity仍占位且影响交互与无障碍。
display: none 配合 @media 媒体查询是最可靠、最可控的方式。其他方法如 visibility: hidden、opacity: 0 或 hidden 属性，要么保留占位、要么不响应视口变化、要么被 CSS 覆盖，都不适合“按设备隐藏”这个明确需求。
为什么必须显式写默认 display 值
只在媒体查询里写 .ad-banner { display: none; }，却不给它设基础状态，浏览器会回退到默认 display（比如 block、inline-block 或框架注入的 flex），一旦遇到重置样式或 UI 库，就失效。
- 正确做法：先定义基础状态，再覆盖 ——
.ad-banner { display: block; }，然后@media (max-width: 768px) { .ad-banner { display: none; } } - 更推荐移动优先：默认
.ad-banner { display: none; }，再用@media (min-width: 769px)恢复显示，逻辑更清晰、断点多时不易冲突 - 断点值别硬套 768px：iPhone 14 Pro 是 390px，Pixel 7 是 360px，iPad Air（第5代）横屏是 820px —— 建议用 360px、414px、768px、1024px 四档，并加
and (pointer: coarse)辅助判断触屏设备
为什么不能用 hidden 属性替代媒体查询
hidden 是静态布尔属性，一加上就彻底隐藏，不随视口缩放、旋转或设备切换而变化。它无法表达“小屏隐藏、大屏显示”这种条件逻辑。
- 写
<div hidden class="sm:block"> 会失效 —— <code>hidden的优先级高于大多数类名，sm:block根本不起作用 - 它适合 JS 动态开关（如
el.hidden = isEditing），但不是响应式方案 - 服务端渲染时若提前设了
hidden，客户端 JS 还没执行前，用户看到的就是空内容；而 CSS 媒体查询由浏览器原生解析，无此风险 -
visibility: hidden：侧边栏设了它，主内容区仍被挤到右边，留下大片空白；且getBoundingClientRect()返回真实尺寸，JS 初始化高度计算可能出错 -
opacity: 0：按钮看不见，但tab键还能聚焦、手指点击仍有响应、屏幕阅读器照读不误 —— 必须配pointer-events: none和tabindex="-1"才算“真隔离” - 两者都不该用于响应式显隐控制，仅限动画过渡（如
opacity+visibility组合淡入）或 DOM 尺寸稳定场景（如预加载容器） - 测试 tab 键是否还会聚焦到该区域：不该聚焦的元素，要确保其子节点（尤其是
button、a）已完全脱离焦点流 - 真机点一下原位置：确认无 click/touchstart 响应，特别是广告 Banner 或悬浮按钮这类高频误触区域
- 检查 SSR/SEO 行为：Next.js、Nuxt 等框架服务端返回的 HTML 仍含该元素，搜索引擎可能索引 —— 若内容敏感，需配合
robots.txt或服务端条件渲染
为什么 visibility: hidden 和 opacity: 0 在响应式里是坑
它们看起来“隐藏了”，但实际仍在文档流中，对布局、焦点、事件、可访问性都留有后门，极易引发意外交互或错位。
移动端隐藏后必须检查的三件事
用 display: none 隐藏后，视觉上没问题，但容易漏掉运行时副作用。
立即学习“前端免费学习笔记（深入）”；
display，并始终控制好默认状态和断点语义。所有“看起来隐藏”的替代方案，都在悄悄埋下可访问性、布局、JS 行为三方面的雷。
