flex: 1 比 width: 33.33% 更可靠，因其基于 flex-basis: 0 均分剩余空间，规避小数像素舍入误差；需配合 min-width: 0 和父容器明确宽度，并注意下拉菜单时 li 必须 relative 定位及避免嵌套干扰。
直接用 display: flex + flex: 1 就能等分，不需要算百分比、不用 grid-template-columns、更别碰 float —— 后两者在等宽导航场景下要么冗余，要么埋坑。
为什么 flex: 1 比 width: 33.33% 更可靠
浏览器对小数像素的舍入处理不一致，width: 33.33% 在某些分辨率下会累计误差，导致第三项换行或右侧留白；而 flex: 1 是弹性分配逻辑，由 Flex 格式化上下文统一计算剩余空间，天然规避舍入问题。
-
flex: 1等价于flex: 1 1 0，其中flex-basis: 0是关键——它让所有子项从“零宽度”开始均分容器，不依赖内容撑开 - 若某项文字过长，默认会拉伸破坏等分，需加
min-width: 0配合overflow: hidden或text-overflow: ellipsis - 父容器必须有明确宽度（比如
width: 100%或处于块级上下文中），否则 flex 无法知道“剩余空间”是多少
遇到 hover 下拉菜单时，等分逻辑容易崩的原因
下拉菜单通常靠 position: absolute 实现，但它的父级 <li> 若没设 position: relative，下拉层会脱离当前列定位，视觉上“飘走”；更隐蔽的问题是：若 <li> 内部用了 display: inline-block 或未清除浮动，flex: 1 会误判其尺寸，导致宽度计算异常。
- 确保每个导航项
<li>是flex的直接子元素，中间不要嵌套额外<div> <li>下拉容器（如 <code><ul class="submenu"></ul>）必须放在对应<li>内部，且该<li>加position: relative - 避免给
<li>设width或max-width，这会覆盖flex: 1的分配行为 - 容器设
display: grid; grid-auto-flow: column; grid-auto-columns: 100%;—— 每个<li>自动成为一列，宽度 = 视口宽度 - 加
overflow-x: auto; -webkit-overflow-scrolling: touch;保证 iOS 滚动顺滑 - 此时“等宽”是自然结果，不是靠 flex 分配，也不依赖 JavaScript 计算
- 注意：这种写法下
flex: 1失效，别混用
移动端横向滚动导航也想等宽？别用 flex-wrap
在窄屏上把三列导航压成一行并允许横向滚动，常见错误是设 flex-wrap: nowrap + width: 300%，结果第二列边缘常“漏出一点”，用户还没滑就看到部分内容。真正干净的做法是切换为 display: grid，用自动列流机制：
立即学习“前端免费学习笔记（深入）”；
最易被忽略的一点：等分只在“内容长度相近”时视觉稳定；如果某个导航项文字特别长（比如“关于我们与企业社会责任践行报告”），即使加了 min-width: 0，字体渲染微小差异仍可能造成 1px 偏差。真要严控，得用 text-overflow: ellipsis 截断，而不是指望布局引擎替你修像素。
