移动端底部导航栏不必用<nav>包裹，语义上推荐但非必需；真正起作用的是CSS布局和ARIA属性，如role="navigation"即可满足基础可访问性要求。
移动端底部导航栏必须用 <nav> 包裹吗？
不用。语义上更推荐用 <nav>，但实际渲染和交互不依赖它；真正起作用的是 CSS 布局和 ARIA 属性。很多项目直接用 <div class="bottom-nav"> 更轻量，只要补上 role="navigation" 就能通过基础可访问性检测。
关键点：
-
<nav>是语义标签，对 SEO 和屏幕阅读器友好，但不解决点击区域小、点击反馈缺失等真实问题 - 如果导航项少于 5 个（常见为 3–5），优先用
<footer>+position: fixed组合，避免<nav>被误读为页面主导航 - 不要在底部导航里嵌套
<header>或<main>—— 会破坏 DOM 层级逻辑
position: fixed 在 iOS Safari 上为啥会“跳”？
这是 iOS 15+ 的已知行为：地址栏收起/展开时触发 viewport 高度重算，fixed 元素会短暂错位。根本原因不是 CSS 写错了，而是 Safari 把地址栏高度变化当作了 viewport resize 事件。
实操解法（选一个）：
立即学习“前端免费学习笔记（深入）”；
- 用
position: sticky替代：bottom: 0+ 父容器设height: 100vh，兼容性够用（iOS 15.4+、Android Chrome 98+） - 加一层 wrapper 并监听
resize事件，动态设置top: calc(100vh - 60px)（60px 是导航高度），但需防抖，否则卡顿 - 最稳方案：放弃
fixed，把底部导航放在<body>最末尾，用margin-bottom: 60px预留空间，靠内容撑开页面 —— 适合内容高度固定或可预测的场景
图标 + 文字的点击热区怎么保证 ≥44px？
WCAG 和 Apple HIG 都要求最小触控目标 44×44pt（约 44px @1x）。但很多人只给 <i> 或 <span> 设宽高，忽略了文字行高和内边距的实际占用。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
正确做法：
- 给每个导航项（
<a>或<button>）设min-width: 44px、min-height: 44px、padding: 12px 8px（上下 padding 补足高度，左右留白防误触） - 图标用
<svg>内联，设width: 24px、height: 24px，不要用 background-image —— 否则无法随文字缩放 - 文字用
font-size: 12px（iOS 推荐），配合line-height: 1避免额外行高溢出热区 - 禁用
touch-action: manipulation—— 它会禁掉双击缩放，反而影响部分老年用户
如何让当前页 Tab 有视觉反馈又不破坏语义？
用 aria-current="page" 是标准解法，比单纯加 class 更可靠。它会被 VoiceOver、TalkBack 主动读出，且不影响样式控制。
示例结构：
<nav role="navigation">
<a href="/home" aria-current="page">
<svg>...</svg>
<span>首页</span>
</a>
<a href="/search">
<svg>...</svg>
<span>搜索</span>
</a>
</nav>对应 CSS 可这样写：
a[aria-current="page"] svg { color: #007AFF; }
a[aria-current="page"] span { font-weight: 600; }注意点：
- 不要用
aria-selected="true"—— 它适用于 tablist、listbox 等复合组件，底部导航是独立链接集合 - 不要在 JS 中动态删改
aria-current后不触发focus()—— 当前项应自动获得焦点，否则键盘用户无法感知 - 如果用前端路由（如 React Router），确保每次路由变化后，
aria-current被准确同步到对应<a>
最常被忽略的其实是状态持久化：用户从详情页返回列表页，底部导航的高亮状态是否还对？这需要路由系统或 history.state 配合判断，而不是仅靠 URL pathname 截取 —— 特别是带 query 参数或 hash 的路径。
