必须用nav+ul+li结构，因这是浏览器和辅助技术识别导航意图的语义链：nav标识主导航区，ul表示并列项（读屏器播报“共X项”），li必须直接包裹a以确保:hover/:checked~选择器有效；用div替代会导致Tab错乱、SEO降权、焦点失控。
nav + ul + li 是响应式顶部导航的语义基底，不是“推荐写法”，而是不可绕过的硬性结构。漏掉任一环，小屏下菜单就卡死、焦点错乱或读屏器完全失语。
为什么必须用 nav + ul + li 而不是 div
浏览器和辅助技术依赖这套语义链：nav 告诉读屏器“这是主导航区”，ul 表示一组并列项（读屏器会报“共 4 个菜单项”），li 必须直接包裹 a，否则 :hover 或 :checked ~ 选择器在移动端会失效。
用 div 替代的后果是真实的：Tab 键顺序跳变、SEO 权重下降、iOS 上焦点框消失、键盘用户无法进入下拉菜单。
display: flex 在桌面端怎么写才不压扁文字
给 nav ul 设 display: flex 是起点，但关键细节常被忽略：
- 用
justify-content: space-around，比space-between更稳——文字长度不均时两端留白一致，视觉不飘 - 每个
li加flex: 0 0 auto，禁止缩放；别设flex-shrink: 1，否则窄屏下文字被压扁甚至换行错乱 - 间距统一用
gap: 1rem，比给每个li加margin-right干净；IE11 不支持gap，得退回到li:not(:last-child) { margin-right: 1rem; }
移动端展开为什么非用 input[type="checkbox"]
纯 CSS 实现点击展开/收起，唯一可靠方案就是 input[type="checkbox"]。常见错误是直接写 div.hamburger 配 JS，但 JS 加载失败时菜单永远不可见。
-
input必须放在label前，用for关联，确保点击区域 ≥ 44px（iOS 最小触控要求） -
ul.nav-menu默认设max-height: 0; overflow: hidden;，别用display: none（它无法触发 CSS 过渡） - 触发时靠
input:checked ~ .nav-menu设max-height: 300px，数值需略大于所有子项总高；别写死300px——动态增减项时得预估或交由 JS 补充
grid-template-columns: repeat(auto-fit, minmax(240px, 1fr)) 为什么不是万能公式
这行代码只是起点，不是终点。它只分配轨道，不管内容是否溢出：
- 卡片内的
img若没加max-width: 100%和height: auto，原始宽高比会强行撑开网格项，导致横向滚动 - 长单词（如 URL、技术名词）需
overflow-wrap: break-word，否则溢出容器 - 卡片若含 Flex 容器，内部子项默认有
min-width: auto，得显式写min-width: 0防止拉伸 -
gap: 12px是安全值；避免gap: 1rem，rem 会随根字体缩放，破坏网格节奏
repeat(auto-fit, minmax())，而是所有子元素都得“守规矩”：图片不抢空间、文字不锁尺寸、伪元素不越界、滚动条宽度不被忽略——任何一个点松动，整个响应式布局的稳定性就从那里开始瓦解。 
