纯HTML无法实现响应式侧边导航栏，必须依赖CSS的@media、flex、position:sticky和:checked等特性，并严格遵循nav+ul+li语义结构以保障可访问性与功能正确性。
纯 HTML 无法实现响应式侧边导航栏——它只提供语义骨架，真正起作用的是 CSS 的 @media、flex、position: sticky 和状态选择器（如 :checked）。结构写错，再漂亮的 CSS 也救不回来。
为什么必须用 nav + ul + li 套路
这不是“看起来规范”，而是浏览器和辅助技术依赖这套语义链理解导航意图：
-
nav告诉读屏器“这是主导航区”，缺失会导致键盘 Tab 顺序错乱、SEO 权重下降 -
ul表示一组逻辑并列项，比div更利于屏幕阅读器播报“共 6 个菜单项” -
li必须直接包裹a，不能跳级；否则子菜单嵌套时，:hover或:checked ~选择器会失效 - 下拉子菜单必须作为对应
li的直接子元素（即li > ul），否则移动端展开后定位偏移、焦点管理失控
input[type="checkbox"] 是唯一零 JS 实现点击展开的可靠方案
想不用 JS 控制侧边栏显隐？input[type="checkbox"] 是目前唯一能被 CSS 精准监听状态的原生控件。常见错误是用 div 配 JS，但 JS 加载失败时菜单永远不可见。
- 把
input放在label前，用for关联，确保点击区域 ≥ 44px（iOS 最小触控要求） -
.sidebar默认设max-height: 0; overflow: hidden;，避免用display: none（它无法触发 CSS 过渡） - 触发时靠
input:checked ~ .sidebar设max-height: 320px—— 数值需略大于所有子项总高，否则动画截断；别写死，动态项多时得预估或补 JS - IE11 不支持
max-height动画，得退回到opacity+transform组合过渡
flex-shrink: 0 和 min-width 是防止侧边栏塌缩的关键
侧边栏在 flex 布局里被压缩、在小屏下突然撑满全屏，几乎全是没切断父级影响造成的：
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
- 给侧边栏最外层加
flex-shrink: 0，防止在display: flex的父容器中被挤压变形 - 用
min-width: 240px而非width: 240px控制基础尺寸，兼容折叠逻辑（比如收起后留窄条图标区） - 固定定位（
position: fixed）时，务必同时设top: 0和left: 0，否则 Safari 中可能轻微偏移 - 若要随页面滚动，改用
position: sticky，但必须确保其父容器有明确高度或overflow: visible，否则粘性失效
响应式切换不能只靠 @media，必须配合 DOM 可访问性控制
单纯用媒体查询 display: none 隐藏侧边栏，DOM 仍存在、焦点可抵达、屏幕阅读器仍播报——这不是“隐藏”，是“假装看不见”。
- 移动端真隐藏，得用
aria-hidden="true"+inert属性（现代浏览器支持），或彻底移除焦点流（tabindex="-1"+ 移除href） - 当前页高亮不能硬编码
class="active"，静态写死等于埋雷；前端判断必须基于window.location.pathname，且要用new URL(link.href).pathname标准化路径 - 子菜单展开状态要用
aria-expanded和aria-haspopup="true"同步更新，否则读屏器无法感知交互变化
侧边栏最容易被忽略的不是动画效果，而是语义链断裂和焦点流失控——一个没设 role="navigation" 的 nav，或一个漏掉 aria-current="page" 的当前项，在残障用户眼里就是不可用的。
