响应式菜单应按容器宽度而非固定视口断点判断，用 container 查询或 48rem + 触摸媒体查询；flex-wrap 实现多行自适应，IE11 降级为 inline-block；汉堡菜单需同步 aria-expanded、hidden 及焦点管理；下拉菜单须 JS 控制并兼容触摸，预留 44×44px 热区。

用 @media 控制菜单断点，别硬套 768px

很多项目直接抄「max-width: 768px」做移动端菜单，结果在 iPad Pro（1024px 宽但常横屏）、Surface Go（1366px 但小屏）上体验割裂。真实做法是按容器而非视口判断：给菜单外层加 class="nav-container"，用 container 查询或 JS 监听其宽度变化。纯 CSS 方案更稳——把断点设在 48rem（即 768px，但基于根字体大小），同时补一条 @media (hover: none) and (pointer: coarse) 捕获触摸设备，触发汉堡菜单。

display: flex + flex-wrap 实现多行自适应导航项

横向菜单撑出滚动条？说明没处理换行逻辑。主容器设 display: flex 和 flex-wrap: wrap，子项用 flex: 1 1 calc(25% - 1rem)（四列布局，留间隙），再配合 min-width: 120px 防止单项过窄。注意：IE11 不支持 flex-wrap，若需兼容，得用 display: inline-block + text-align: justify 模拟，但会丢失对齐精度。

汉堡菜单的 aria-expanded 和焦点管理不能省

点击后菜单展开但屏幕阅读器不知道状态？必须同步操作 aria-expanded 属性和 hidden 属性。更关键的是焦点流：button 点击后，焦点要立刻移到第一个可聚焦元素（如首个 a 或 button），关闭时焦点需回到原触发按钮。漏掉这点，键盘用户会卡死在空白处。示例中用 document.querySelector('.nav-menu a, .nav-menu button').focus() 实现，但得加 try/catch 防止空节点报错。

const menuBtn = document.querySelector('[aria-controls="main-nav"]');
const menu = document.getElementById('main-nav');
menuBtn.addEventListener('click', () => {
const isExpanded = menuBtn.getAttribute('aria-expanded') === 'true';
menuBtn.setAttribute('aria-expanded', !isExpanded);
menu.hidden = isExpanded;
if (!isExpanded) {
try {
menu.querySelector('a, button').focus();
} catch (e) {}
}
});

悬停下拉菜单在触摸设备上会失效

纯 :hover 触发的二级菜单，在 iOS 和 Android 上基本不可用——第一次点击只触发 hover，第二次才跳转。必须改用 JS 控制显隐，并用 touchstart + click 双事件绑定。同时加个 300ms 延迟判断是否为真点击（防误触），否则快速连点会闪退。另外，下拉区域要预留至少 44×44px 点击热区，否则手指点不中。

响应式菜单最难的不是写样式，是判断「什么时候该收起」「谁该获得焦点」「触摸和悬停如何共存」——这些细节没测到真实设备上，代码就只是看起来能跑。