够用，但易误删关键交互节点；需确认元素是否参与可访问性流或被脚本依赖，且必须用@media限定范围，避免全局隐藏、高dpr误判及嵌套过深。
移动端用 @media 配合 display: none 真的够用吗？
够用，但容易误删关键交互节点。比如把 <nav></nav> 或带 aria-expanded 的折叠按钮直接 display: none，会导致屏幕阅读器跳过、键盘焦点丢失、JS 判断 offsetParent === null 失败。隐藏前先确认该元素是否参与可访问性流或被脚本依赖。
为什么不能只写 display: none 而不加媒体查询？
因为会全局生效，PC 端也看不见了。必须用 @media 限定范围，常见写法是：
@media (max-width: 768px) {
.sidebar, .desktop-only {
display: none;
}
}
-
768px不是绝对标准，需对齐项目实际断点（比如用theme.breakpoints.down('sm')的 MUI 项目可能对应600px） - 别用
min-device-width—— 它检测物理像素，易在高 DPR 屏幕上错判 - 避免嵌套多层
@media，CSS 优先级和维护成本会陡增
visibility: hidden 和 display: none 在隐藏时差别在哪？
差别很大：display: none 彻底脱离文档流，不占空间、不触发重排；visibility: hidden 还占位、能响应伪类（如 :hover），且子元素设 visibility: visible 仍可见。
- 要“真隐藏+省渲染开销” → 选
display: none - 要“暂时藏但保留布局/动画过渡” → 用
visibility: hidden+opacity: 0 - 别混用：比如给父元素
display: none后再对子元素设visibility: visible，无效
隐藏后 JS 拿不到元素？常见原因和绕过方式
不是拿不到，是 DOM 还在，只是渲染层不可见。但部分逻辑会出问题：
-
element.offsetWidth === 0或getBoundingClientRect().width === 0成立，可作判断依据 -
element.hidden = true是语义化替代方案，兼容性好（IE11+），且与display: none行为一致 - 若用
querySelector找不到，检查是否写错了选择器，或元素本身被 JS 动态移除了（不是隐藏）
真正难处理的是那些靠 offsetHeight > 0 做懒加载或滚动监听的代码——它们在 display: none 下永远不触发，得提前在媒体查询生效时手动触发一次逻辑，或改用 IntersectionObserver 并传 {threshold: 0}。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
