推荐用max-width:480px覆盖小屏手机，min-width:481px且max-width:1024px覆盖主流平板横竖屏，避免768px单一断点；导航HTML结构必须唯一，通过类名切换状态；平板导航需适配触控，禁用纯:hover菜单，行高≥48px、文字≥16px、留白≥24px。
用媒体查询区分手机和平板的断点值
手机和平板导航栏的核心差异不在设备类型，而在视口宽度。别信“iPad是平板所以用768px”这种过时经验——现代折叠屏、大屏手机、横屏平板让固定像素断点容易失效。@media 的关键不是猜设备，而是按内容撑开程度来切。
- 推荐用
max-width: 480px覆盖小屏手机（含竖屏iPhone SE） - 用
min-width: 481px和max-width: 1024px包住主流平板横竖屏（iPad Air、Surface Go等） - 避开
768px单一断点：很多安卓平板竖屏就是768px，但字体小、交互区窄，实际体验更接近手机 - 真要兼容折叠屏，加一条
screen and (min-aspect-ratio: 13/9)辅助判断横屏倾向
导航HTML结构必须同一套，不能写两套DOM
写两套 <nav></nav> 标签再用 display: none 切换，是性能和可访问性灾难。屏幕阅读器会读两遍，JS绑定事件要重复处理，CSS重绘也更重。
- 只保留一个
<nav class="main-nav"></nav>，所有状态通过类名控制：main-nav--mobile/main-nav--tablet - 汉堡按钮（
menu-toggle）始终存在，但只在手机断点下visibility: visible；平板断点里它display: none，但导航项直接显示 - 绝对不要用
document.write或 JS 拼接两套 HTML——加载慢、SEO差、服务端渲染（SSR）直接崩
平板导航要防“伪桌面化”：别直接照搬PC样式
平板触控精度远低于鼠标，但又比手机手指操作空间大。直接把PC的 hover 下拉菜单或细高导航栏搬过去，用户点不中、误触多、返回困难。
- 平板导航项行高至少
48px，文字大小不小于16px，左右留白 ≥24px - 禁用纯
:hover触发二级菜单——触摸设备没 hover 状态，要用click+ JS 切换is-open类 - 如果导航项超过5个，平板上优先用带图标的横向滚动容器（
overflow-x: auto），别强行折行或缩小字号 - 注意
touch-action: manipulation加在导航链接上，减少 iOS Safari 300ms 点击延迟
测试时最容易漏掉的三个真实场景
模拟器调个 768×1024 就算完事？现实里用户会在奇怪时间做奇怪操作。
立即学习“前端免费学习笔记（深入）”；
- 平板横屏→旋转成竖屏→快速点开导航→再转回横屏：检查
window.matchMedia监听是否及时更新类名，别卡在旧状态 - Chrome DevTools 里关掉 “Disable cache”，再用 Network 面板选 “Slow 3G”，看导航 DOM 是否在弱网下仍能正确初始化（尤其依赖 JS 切换类名时）
- 用 iOS 真机访问，打开系统设置→辅助功能→显示与文字大小→把“更大字体”拉到最右：很多平板导航文字会被裁掉，得用
clamp(16px, 4vw, 20px)替代固定字号
断点不是写死的数字，是内容与容器反复拉扯后妥协出来的值。每次改完，拿三台真机（小屏安卓、iPad、折叠屏）各转两次屏再点三次导航，才敢说“差不多了”。
