标签是强制语义要求，不用则读屏器不识别导航区域、键盘无法跳转、搜索引擎降权；必须用真实 href、正确结构、可访问交互设计。
nav 标签不是可选，是强制语义要求
不用 <nav></nav>，读屏器就当那段是普通段落，不会提示“导航区域”，键盘用户按 Ctrl+Alt+Insert+N（NVDA）或 D（JAWS）根本跳不过去。搜索引擎也会降权处理——这不是“更好看”，而是“能不能被正确识别”的问题。
常见错误现象：<div class="nav">@#@#@#@#@#@#@#@#@#@0 在 <code>/blog 页面里还是没 class；或者用 JS 动态判断 window.location.pathname 再加 class，但 JS 加载失败时整个高亮逻辑就崩了。
- 推荐写法：
@#@#@#@#@#@#@#@#@#@1（仅在/blog页面中出现） - CSS 写
a.active { background-color: #007bff; color: white; }，别只写.active，避免样式污染其他元素 - 如果导航项是多级（如 Element Plus 的
.el-submenu），上级菜单高亮需额外加::v-deep(.el-submenu.is-active > .el-submenu__title)这类穿透选择器
移动端折叠菜单必须用 :checked + ~ 选择器，而非 JS 切 class
依赖 JS 控制汉堡菜单显隐，一旦脚本加载失败或被拦截，菜单就完全不可用。CSS-only 方案用 <input type="checkbox" id="menu-toggle"> + <label for="menu-toggle"></label> + :checked ~ 选择器，更可靠、更轻量、也更符合渐进增强原则。
关键细节：下拉菜单 <ul></ul> 必须用 position: absolute 或 top: 100% 脱离文档流，否则展开时会撑开页面导致布局跳动；overflow: hidden 配合 max-height 做展开动画比 display: none/block 更平滑。
- 别漏掉
<meta name="viewport" content="width=device-width, initial-scale=1">，否则媒体查询在 iOS 上直接失效 -
label必须用for显式关联input，不能靠 DOM 顺序或 JS 绑定 - 键盘用户需要
tabindex="0"和role="button"支持，否则Space/Enter无法触发 checkbox
最容易被忽略的是：所有交互状态（:hover、:focus、:active、:checked）必须成对设计。只做 hover 却没 focus 样式，键盘用户就卡在第一个菜单项上出不去；只做 active 却没 visited 基础样式，Safari 下整个悬停反馈就消失。可访问性不是加几个 ARIA 属性就完事，是整条交互链路都得稳。
