纯HTML无法实现响应式布局，仅提供语义骨架；真正起效的是CSS的@media、flex和grid，配合nav+ul+li结构保障可访问性、SEO及移动端交互稳定。
纯 HTML 无法实现响应式布局，它只提供语义骨架；真正起效的是 CSS 的 @media、display: flex 和 display: grid 配合合理的 HTML 结构。结构写错，再精细的 CSS 也会在辅助技术、SEO 或移动端交互上出问题。
为什么必须用 nav + ul + li 写导航
这不是“看起来规范”，而是浏览器和读屏器依赖这套语义链理解导航意图：
-
nav告诉辅助技术“这是主导航区”，缺失会导致键盘 Tab 顺序错乱、焦点跳转异常 -
ul表示一组逻辑并列项，屏幕阅读器会播报“共 5 个菜单项”；用div包裹就失去该能力 -
li必须直接包裹a，不能跳级（如li > span > a），否则:hover或:checked ~选择器在下拉菜单中失效 - 子菜单必须是对应
li的直接子元素（即li > ul），外置或平级会导致移动端展开后定位偏移、焦点无法进入
移动端汉堡菜单的 checkbox 实现要点
不用 JS 就能实现开关逻辑，但细节一错就全崩：
- 必须用
input[type="checkbox"]模拟状态，而非div+ JS——JS 加载失败时菜单永远不可见 -
input要放在label前，并用for属性绑定，确保点击区域 ≥ 44px（iOS 最小触控要求） -
.nav-menu默认设max-height: 0; overflow: hidden;，别用display: none——它无法触发 CSS 过渡动画 - 触发时靠
input:checked ~ .nav-menu设max-height: 300px，这个值得略大于所有子项总高；若菜单项动态增减，max-height: fit-content在过渡中不生效，需预估或交由 JS 补充
flex 布局中 gap 和 justify-content 的实际取舍
桌面端横向排列看似简单，但空格、换行、对齐细节极易翻车：
立即学习“前端免费学习笔记（深入）”；
- 用
gap: 1rem控制li间距，比给每个加margin-right干净得多，也规避了“最后一个要不要清 margin”的纠结 -
justify-content: space-around比space-between更适合文字长度不均的导航项——两端留白一致，视觉更稳 - 右对齐登录/注册项，直接给对应
li加margin-left: auto，别用float: right或绝对定位——它们破坏 Flex 流，导致键盘焦点顺序错乱 - IE11 不支持
gap，得退回到margin-right并手动处理最后一个子项：li:not(:last-child)加margin-right
当前页高亮为什么不能硬编码 class="active"
静态写死 class="active" 在所有页面里，等于埋下维护雷：
- 路径稍有差异（如
/aboutvs/about/vs/about#team）就失效 - 前端判断必须基于
window.location.pathname，且要标准化链接路径：new URL(link.href).pathname - 服务端渲染（SSR）场景下，需同步保证初始 HTML 中的 active 状态与客户端一致，否则出现闪烁或焦点错位
最易被忽略的其实是语义链断裂：比如把 nav 放在 header 外、用 div 替代 main、或让 footer 包含非页脚内容——这些不会立刻报错，但会在无障碍测试、SEO 抓取、甚至某些浏览器的“阅读模式”中悄然失效。
