现代项目不推荐用float实现横向导航，因其导致父容器塌陷、子菜单错位、移动端点击不可靠；应改用display: flex，天然解决高度计算、对齐与顺序管理问题。
别用 float，现代项目直接上 display: flex —— 否则后续加响应式、二级菜单、移动端交互会反复踩坑。
为什么 float: left 在横向导航里越来越不推荐
老教程里让 li 浮动实现横排，看似简单，但实际带来三个硬伤：父容器高度塌陷（得额外清浮）、:hover 子菜单错位（尤其在缩放或动态内容下）、移动端点击区域不可靠（iOS Safari 对浮动元素的 touch 响应不一致）。这些不是“写法问题”，而是布局模型本身的局限性。Flexbox 天然解决高度计算、对齐控制和顺序管理，ul 一行声明 display: flex 就能稳住整个导航流。
display: flex 实现基础横向导航的关键写法
核心不在“怎么让 li 横着排”，而在于控制容器行为和子项尺寸分配：
-
ul必须设display: flex，且推荐加flex-wrap: nowrap防意外折行 -
li不要设宽，用flex: 0 0 auto保持内容自适应，避免小屏溢出 -
a标签必须是块级（display: block），否则 padding/margin 不生效；若需居中文字，优先用text-align: center而非line-height匹配 height（后者在字体混排时易错位） - 如果导航需要等宽铺满容器，改用
li { flex: 1 }，但注意：纯数字链接或中英文混排时，视觉上仍可能不均——此时应配合min-width保底
二级横向菜单的 DOM 结构和 CSS 定位陷阱
常见错误是把二级 ul 放到一级 li 外面，或者塞进 a 标签里。正确结构必须是：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
<li>
<a href="#">产品</a>
<ul class="submenu">
<li><a href="#">Web</a></li>
<li><a href="#">App</a></li>
</ul>
</li>
对应 CSS 要点：
- 一级
li设position: relative，为子菜单提供定位上下文 - 二级
ul默认display: none，li:hover > .submenu触发display: flex（不是block）才能横向展开 - 二级
ul加position: absolute; top: 100%; left: 0;，并设z-index: 1000防被遮挡 - 移动端无法依赖
:hover，必须用 JS 切换.is-open类，否则 iPad 点一次弹出、再点才跳转，用户会以为卡死
固定在顶部时最常漏掉的两件事
position: fixed; top: 0; width: 100% 只是第一步。真正上线前必须检查：
-
body缺少padding-top：固定导航会盖住正文首屏，值必须 ≥ 导航实际高度（含 border/padding），不能只写60px了事 -
z-index冲突：某些 UI 库（如 Bootstrap 的 modal）默认z-index: 1050，若导航只设1000，弹窗就会压在导航下面——查浏览器开发者工具的 computed z-index 才算数
横向导航本身不难，难的是它作为页面第一交互层，任何样式或结构松动都会放大成体验断层。特别是二级菜单的触发逻辑、固定定位的层级关系、以及移动端 fallback 方案，这三处最容易在测试阶段才暴露，但修复成本远高于初期设计时多花五分钟确认。
