仅用<nav>标签和媒体查询无法实现可用响应式导航，必须补足Flexbox布局、状态切换机制（如checkbox）和触控适配（44×44px点击区），否则小屏下会溢出或点击无响应。
纯用 <nav> 标签 + CSS 媒体查询就能做出可用的响应式导航菜单，但必须补足 Flexbox 布局、状态切换机制和触控适配这三块，否则小屏下要么堆成一行溢出，要么点击无反应。
为什么只写 <nav><ul><li> 不行
HTML 语义标签本身不带响应行为。<nav> 只是告诉浏览器“这是导航区域”，它不会自动折叠、对齐或隐藏。常见错误是写完结构就加 @media，结果发现移动端 <ul> 仍强行横排、文字挤在一起、汉堡按钮点不动——根本原因是没切断默认文档流，也没提供状态切换锚点。
- 桌面端需用
display: flex控制主菜单横向排列，不能靠float或inline-block拼凑 - 移动端必须引入一个可触发的状态开关（如
<input type="checkbox">），仅靠@media无法响应用户点击 -
<nav>默认不设高度/溢出控制，小屏下内容会撑破容器，得手动加overflow: hidden和过渡属性
@media 断点该设多少
别死守 768px 或 480px。实际应以内容为准：当菜单项开始换行、文字被截断、图标间距小于 8px 时，就是该触发断点的信号。多数项目用 @media (max-width: 768px) 是因它覆盖 iPad 竖屏临界值，但若你的导航只有 3 个短词，640px 就够；若含 logo + 搜索框 + 5 个链接，可能得提前到 920px。
- 桌面端样式写在媒体查询外（默认生效），移动端覆盖写在
@media内 - 避免嵌套多层
@media，同一断点内统一控制所有相关元素（<nav>、<ul>、<label>） - 不要用
user-scalable=no锁定缩放，它会让触控点击区域失效，且被现代 iOS Safari 警告
汉堡菜单必须用 <input type="checkbox"> 吗
不是“必须”，但它是目前最轻量、最可靠的选择。JS 方案（如 menuActive 切换 class）依赖脚本加载完成，网络慢或 JS 报错时菜单永远收起；而 checkbox 的 :checked 是原生 CSS 状态，无需执行逻辑，兼容性覆盖 IE9+。
- 把
<input id="nav-toggle">放在<label>前，用for="nav-toggle"关联，确保整个 label 区域都可点击 - 移动端
<ul>默认设max-height: 0; overflow: hidden;，:checked ~ ul设max-height: 300px（数值略大于所有<li>总高，不能写none，否则过渡失效） - 禁用
display: none切换，它不触发 transition；改用visibility: hidden+opacity: 0或仅靠max-height
Flexbox 对齐在桌面端怎么控制右对齐项
别用 margin-left: auto 给最后一个 <li>，那会破坏语义结构。正确做法是让 <ul> 成为 flex 容器，把登录/注册等操作项单独包一层 <div class="nav-actions">，然后对这个 div 设置 margin-left: auto。
-
<nav>设display: flex; align-items: center; -
<ul>设display: flex; list-style: none; margin: 0; padding: 0; -
<div class="nav-actions">放在<ul>内部末尾，加margin-left: auto; - 触屏设备上，每个可点区域（
<a>、<label>）最小尺寸要 ≥ 44×44px，用padding补足，别只靠字体大小撑空间
真正难的不是写出能动的菜单，而是让所有设备下的点击反馈一致、动画不卡顿、焦点管理不出错——这些细节藏在 max-height 数值、transition-timing-function 选择和 touch-action 属性里，容易被忽略，但直接影响用户是否觉得“卡”或“点不中”。
