hidden 属性使元素逻辑上不存在，导致布局塌陷、getBoundingClientRect() 返回0、表单不提交、无障碍树忽略；检测应直接用 el.hidden，而非尺寸判断；SSR hydration 时需统一用 el.hidden 而非属性操作。
hidden 属性本身不会导致“逻辑报错”，但它会彻底移除元素在布局流中的存在——包括高度计算、表单提交、可访问性树，甚至 JS 的 getBoundingClientRect() 返回值都可能是 { width: 0, height: 0 }。如果你的代码依赖该元素的尺寸、位置或 DOM 存在性做判断（比如动画起点、滚动锚点、条件渲染开关），hidden 就可能触发意料外的分支逻辑。
为什么 el.hidden = true 后 getBoundingClientRect().height 是 0？
这不是 bug，是规范行为：hidden 声明元素“逻辑上不存在”，浏览器直接跳过其盒模型生成。即使它有 height: 200px 或内联样式，只要 hidden 存在，渲染引擎就不分配空间、不计算几何信息。
- 别用
el.getBoundingClientRect().height > 0来判断元素是否“可见”——它对hidden和display: none都返回0，但语义完全不同 - 想检测是否被
hidden控制，只用el.hidden（布尔值）或el.hasAttribute('hidden') - 若需保留尺寸占位又隐藏视觉，改用
visibility: hidden或opacity: 0+pointer-events: none
hidden 导致父容器高度塌陷的典型误判场景
当子元素带 hidden，而父容器高度依赖子元素撑开（比如无固定高、无 min-height、且无其他非隐藏子元素），父容器高度就会坍缩为 0。这常被误认为是“CSS 没生效”或“JS 没执行”，实则是 hidden 的语义已生效。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 检查父容器
height在 DevTools 的 Computed 面板中是否为0px - 临时删掉子元素的
hidden属性，看父容器高度是否恢复——确认是语义影响而非样式覆盖 - 若必须保留
hidden但又要维持父容器高度，加伪元素占位：.parent::before { content: ""; display: block; height: 200px; }（需知道预期高度） - 更稳妥的做法：用 CSS 类替代
hidden，例如.is-hidden { position: absolute; opacity: 0; pointer-events: none; }，再配合 JS 控制类名
SSR/ hydration 中 hidden 引发的 DOM 不一致问题
服务端渲染时写入 <div hidden></div>，客户端 JS 执行 el.hidden = false 后，DOM 状态变为“未隐藏”，但 el.hasAttribute('hidden') 仍返回 true（因为属性没被移除）。如果后续逻辑依赖 hasAttribute 判断初始状态，就会出错。
立即学习“前端免费学习笔记（深入）”；
- 始终用
el.hidden读取状态，它反映真实渲染逻辑 - 避免在 hydration 后用
setAttribute('hidden', '')/removeAttribute('hidden')，统一走el.hidden = true/false - 若框架（如 React）把
hidden当作普通 prop 处理，确保它透传到真实 DOM 节点，否则语义失效
真正难调试的不是 hidden 本身，而是它和布局计算、JS 尺寸探测、服务端/客户端状态同步之间那些隐式耦合。一旦你开始靠 offsetHeight 或 clientWidth 做条件分支，就得先问一句：这个元素有没有可能被 hidden？
