仅用<nav>标签加@media做不出真正可用的自适应导航栏，因其缺乏Flexbox布局控制、状态切换机制（如input[type="checkbox"]或Bootstrap Collapse）及触控适配（最小点击区≥44×44px、overflow: hidden、ARIA属性同步），导致小屏溢出、点击失效、动画中断等问题。
仅用 <nav> 标签加 @media 查询做不出真正可用的自适应导航栏——缺了 Flexbox 布局、状态切换机制和触控适配，小屏下必然溢出或点不动。
为什么写了 <nav><ul><li><a> 还是不响应？
<nav> 是语义标签，不是功能组件。它只告诉浏览器“这是导航区”，不控制排列、折叠或交互。常见错误现象包括：
- 移动端菜单项仍横排挤在一起，文字被截断
- 汉堡按钮点了没反应，
display: none切换后过渡动画失效 - 点击区域小于 44×44px，手指点不准，尤其 iOS Safari 上触发困难
根本原因是：没切断默认文档流（比如没设 overflow: hidden），也没提供可驱动显示/隐藏的状态锚点（如 input[type="checkbox"]）。
@media (max-width: 768px) 断点该设在哪？
别硬套 768px。这个值只是 iPad 竖屏常见临界点，实际应以内容为准：
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 当菜单项开始换行、图标间距＜8px、文字出现省略号时，就是断点信号
- 若只有 3 个短词（如 Home / Blog / Contact），
@media (max-width: 640px)更合适 - 若含 logo + 搜索框 + 5 个链接，可能得提前到
@media (max-width: 920px)
桌面端样式写在媒体查询外（默认生效），移动端覆盖统一写在同一个 @media 块里，避免嵌套多层查询。
移动端菜单展开必须用 JavaScript 吗？
不是必须，而且不推荐优先用 JS。原因很实际：
- JS 加载失败或执行报错时，菜单永远收起，用户卡死
-
input[type="checkbox"]的:checked是原生 CSS 状态，IE9+ 全兼容，无需等待脚本 - 把
<input id="nav-toggle">放在<label>前，用for="nav-toggle"关联，整个 label 区域都可点击 - 移动端
<ul>初始设max-height: 0; overflow: hidden;，:checked ~ ul设max-height: 300px（不能写none，否则 transition 失效）
禁用 display: none 切换——它不触发 CSS 过渡；改用 visibility: hidden + opacity: 0 或纯靠 max-height 控制高度变化。
Flexbox 对齐和触控适配怎么落地？
桌面端让 <ul> 成为 flex 容器，登录/注册等右对齐项单独包一层 <div>，别用 margin-left: auto，否则破坏语义结构。触控关键点：
- 汉堡按钮和菜单项最小点击区设为
min-height: 44px; min-width: 44px; - 禁用
user-scalable=no——现代 iOS Safari 会警告，且导致点击区域失效 - 移动端
<nav>必须显式设overflow: hidden，否则内容撑破容器 - 如果用 Grid 做菜单项布局，小屏折叠时别用
display: none隐藏整个网格容器，改用visibility: hidden; position: absolute; pointer-events: none;，保留 DOM 结构和尺寸上下文
最易被忽略的是：所有状态切换（如 aria-expanded 和 aria-hidden）必须同步更新，否则屏幕阅读器会读到隐藏内容，可访问性直接归零。
