关键在于三件事：必须加viewport元标签、nav结构要语义清晰（nav+ul+li+a）、@media断点选768px；漏任一都会导致小屏横向滚动或点击失效。
不用框架、不依赖 JS 就能做出可用的自适应导航栏，关键在于三件事：viewport 元标签必须加、nav 结构要语义清晰、@media 断点得选对宽度——漏掉任何一条，小屏上就大概率出现横向滚动条或点击失效。
viewport 元标签漏写会导致整个响应式失效
很多开发者在本地测试时一切正常，一放到手机浏览器里就缩成一团，根本原因是没加这行：
<meta name="viewport" content="width=device-width, initial-scale=1.0">
它不是可选项，而是现代响应式布局的启动开关。没有它，iOS Safari 和 Android Chrome 会按 980px 宽度渲染页面，再自动缩放，导致文字糊成一片、按钮点不准。另外注意：initial-scale=1.0 不能省，否则部分安卓 WebView 会默认放大。
nav + ul + li + a 是最稳妥的 HTML 结构
别用 div 套 span 模拟菜单，也别为了“简洁”删掉 ul。搜索引擎、屏幕阅读器、甚至某些企业内网爬虫都依赖这个结构识别导航意图。
立即学习“前端免费学习笔记（深入）”；
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
-
nav标签包裹整个区域，提供语义锚点 -
ul包含所有导航项，li是每个菜单项的容器 -
a必须带href属性，哪怕只是href="/#about"；避免href="#"，点完会滚顶 - 移动端需要汉堡按钮时，把它放在
nav内部末尾，和ul同级，方便后续用 Flex 对齐
@media (max-width: 768px) 是最常用且可靠的断点
别用 min-width 反向写，也别设成 600px 或 480px —— 这些值在 iPad Mini、Surface Go 等设备上容易错位。768px 覆盖了绝大多数平板横屏和大屏手机竖屏场景，是经过大量真实设备验证的分水岭。
在这个断点里要做的事很明确：
- 把
nav ul设为flex-direction: column，让菜单项垂直堆叠 - 隐藏原生菜单：
nav ul { display: none; }，然后用 JS 或 checkbox 控制显隐 - 显示汉堡按钮：
.mobile-menu-icon { display: block; } - 给
nav加position: relative，为下拉子菜单做准备（如果有的话）
Flexbox 布局中 flex-wrap 和 gap 比 padding 更可控
很多人卡在小屏下菜单溢出，根源是给 li 写了固定像素的 padding-left: 70px。窗口一窄，这些像素不缩，直接撑破容器。
换成 Flex 布局后，重点改这几处：
nav ul { display: flex; flex-wrap: wrap; justify-content: center; gap: 1rem; }-
nav li { flex: 0 0 auto; min-width: max-content; }—— 禁止压缩文字，避免换行错乱 -
nav a { padding: 0.75rem 1.25rem; font-size: 1rem; }—— 用相对单位，随根字体缩放
真正难处理的不是“怎么展开”，而是“展开后下拉菜单不飘、不被截、不闪烁”。这往往取决于父 li 是否有 position: relative，以及子菜单是否用了 transform: translateY(100%) 替代 top: 100% —— 后者在 iOS Safari 上重绘不稳定，容易闪。
