移动端导航需解决触控区域过小（≥44×44px）、点击反馈缺失、滚动穿透（用overscroll-behavior+touch-action替代overflow:hidden）、焦点管理混乱（手动聚焦/恢复+键盘支持）四大问题。
移动端导航不是加个 meta viewport 就能点得顺的——触控区域太小、点击反馈缺失、滚动穿透、焦点管理混乱，这四类问题不解决，用户手指一戳就误操作。
触控目标至少 44×44px，别信“视觉上够大”
iOS 和 Android 的可访问性指南都明确要求最小触控目标为 44×44 CSS 像素（非设备像素）。很多设计师只看设计稿里按钮“看起来挺大”，但实际渲染后 padding 不足、line-height 挤压、父容器 overflow: hidden 裁剪内容，都会让有效点击区缩水。
- 用
min-width: 44px+min-height: 44px强制兜底，而非仅靠内边距 - 确保
a或button是块级或行内块，避免行内元素因line-height导致点击区上下塌陷 - 在真机上用 Chrome DevTools 的「Toggle device toolbar」+ 「Emulate touch events」验证，别只看模拟器
touchstart 代替 click 防 300ms 延迟，但别乱绑
移动端浏览器对 click 事件有约 300ms 延迟，用于判断是否双击缩放。用 touchstart 可立即响应，但直接替换会破坏键盘导航和屏幕阅读器支持。
- 优先用
pointerdown：兼容触控/鼠标/笔，且无 300ms 延迟，现代浏览器支持良好 - 若必须用
touchstart，记得event.preventDefault()后手动触发逻辑，且补上keydown监听（如回车/空格）以保可访问性 - 避免在
document级绑定touchstart，易引发事件冒泡冲突；应限定在导航容器内
菜单展开后禁止背景滚动，但别用 body { overflow: hidden }
弹出侧边栏或下拉菜单时，用户滑动菜单外区域仍会滚动背景页——这不是体验差，是 body 滚动被透传了。粗暴设 overflow: hidden 会导致页面重排、焦点丢失、iOS Safari 滚动条消失后无法恢复。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 改用
position: fixed+inset: 0锁定 body，并记录当前scrollY，菜单关闭后window.scrollTo(0, savedY) - 更稳妥的做法：给
html元素加style="overscroll-behavior: none"，再配合body的touch-action: none阻断透传 - 测试重点：iOS 上弹出菜单后快速两指滑动，确认背景完全静止
焦点管理不能只靠 tabindex，得手动控制
触控用户也可能依赖键盘（如蓝牙键盘配 iPad），或使用 VoiceOver。菜单打开后，焦点没进到第一个可交互项、关闭后没回到触发按钮，等于把辅助功能关上了门。
- 菜单显示后，用
firstFocusableElement.focus()主动聚焦（可用querySelector('button, [href], input')找） - 按
Escape关闭菜单时，同步triggerButton.focus() - 禁用菜单外区域的焦点迁移：给非菜单区域加
tabindex="-1"并aria-hidden="true"，但注意不要影响语义结构
真正难的不是实现展开动画，而是让每一次手指落下都有确定反馈、每一次滑动都被准确截获、每一次焦点转移都不让用户“掉线”。这些细节不写进测试用例，上线后只会出现在用户差评里。
