混合菜单布局需解决多导航共存时的结构冲突、样式污染与交互抢占问题，核心在于语义化html结构、统一flex布局、分层z-index管理、移动端点击与键盘焦点手动接管。
混合菜单布局不是“把几种菜单拼一起”就能跑通的事——它本质是解决「同一页面中，顶部导航、侧边栏、内嵌选项卡、下拉子项」共存时的结构冲突、样式污染和交互抢占问题。直接套用单类菜单代码大概率导致 hover 失效、z-index 错乱、移动端点击无响应、键盘焦点跳失。
ul + li 嵌套结构必须严格对齐层级语义
混合菜单里最常崩的是 HTML 结构。比如顶部水平导航用 <ul></ul>，侧边栏也用 <ul></ul>，但没加独立容器或命名空间，CSS 里的 ul li a:hover 就会跨区域生效。
- 每个菜单区域必须包裹在语义明确的父容器中，如
<nav aria-label="main"></nav>、<aside class="sidebar"></aside>、<section class="tab-section"></section> - 子菜单必须是直接嵌套在对应
<li>内的<ul class="submenu"></ul>，不能用<div> 包着再塞进去——否则 <code>:hover > .submenu会失效 - 多级下拉若用纯 CSS 实现，禁止依赖
:nth-child(n)定位子菜单；改用li.has-submenu:hover > ul，并在 HTML 中显式加class="has-submenu" - 统一用
display: flex控制一级容器（如.header-nav、.sidebar），子项用flex-direction: column或row显式声明流向 - 禁用
float—— 它已不是现代布局手段，且与position: absolute子菜单配合时，父容器无法正确包裹悬停态内容 - 如果必须兼容 IE11，用
display: -ms-flexbox+display: flex双写，但避免混入inline-block和vertical-align - 检查所有带
position: relative/absolute/fixed且设置了z-index的祖先元素，只要它们有opacity 、<code>transform、filter或will-change，就会隔离子元素的 z 层级 - 推荐分层策略：
.header→z-index: 100，.sidebar→z-index: 90，.dropdown-content→z-index: 200，.tab-panel→z-index: 150 - 子菜单绝对定位时，必须确保其父
<li>有position: relative，否则top/left会相对于 body 计算，造成错位 - 为所有可展开菜单项添加
tabindex="0"，并用keydown监听Enter和Space键触发展开 - 用
click事件替代hover控制显示逻辑，同时保留focus状态用于键盘导航 - 点击外部收起菜单时，别只监听
document.body，而要用event.composedPath()判断是否点在菜单区域外，避免 Shadow DOM 场景失效
float / inline-block / flex 混用会导致布局塌陷和换行错位
老教程里顶部菜单用 float: left，侧边栏用 inline-block，选项卡用 display: flex，三者在同一 DOM 树下混用，极易触发 BFC 边界混乱、父容器高度塌陷、文字基线偏移等问题。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
z-index 不是越大越好，要按 stacking context 分层管理
混合菜单里常见现象：下拉菜单被侧边栏遮住、选项卡弹窗被顶部导航盖住、子菜单展开后消失——根本原因不是 z-index: 9999 不够大，而是父元素意外创建了新的 stacking context。
移动端点击穿透和键盘焦点必须手动接管
CSS :hover 在触摸设备上不可靠，纯 CSS 下拉菜单在 iOS/Android 上点一次不展开、点两次才触发，或者点击空白处无法收起——这不是 bug，是规范行为。
真正难的不是写出能显示的混合菜单，而是让顶部导航的 hover 不影响侧边栏的滚动条、让选项卡切换不重置下拉菜单状态、让键盘用户能用 Tab + Arrow 完整遍历所有层级——这些细节一旦漏掉，面试时被追问一句“那盲人怎么用”，就很难圆回来。
