ol li设min-height有效，但需处理ol默认缩进、list-style-position、flex布局对齐、移动端热区及字体大小等干扰因素。
直接给ol li设min-height有效，但需注意父容器和列表样式干扰
在标准 HTML+CSS 中，ol li 是普通块级元素（除非被显式设为 display: inline），所以 min-height 完全可用，不会像 option 那样被浏览器静默忽略。但实际生效常被两个因素掩盖：一是 ol 默认的 padding-left 造成视觉错位，二是某些重置 CSS（如 * { margin: 0; padding: 0; }）意外清除了 li 的默认行高支撑。
实操建议：
- 先确认
li没有被设成display: list-item以外的值（比如flex子项未设align-items: stretch会导致min-height不触发） - 避免仅靠
line-height撑高——它只控制文字垂直居中，不改变盒模型高度；min-height才真正约束容器底线 - 若用
ol做导航菜单，记得重置ol的默认缩进：ol { padding-left: 0; }，否则min-height看起来“没起作用”，其实是被左侧空白挤偏了
ol里li高度不一致？检查list-style-position和counter渲染
有序列表的编号（1.、2.）默认是 outside 定位，会脱离 li 盒子，但它的存在仍可能影响行框高度计算，尤其当字体大小差异大或用了自定义 counter 时。此时即使设了 min-height: 40px，部分 li 可能因编号换行或基线对齐而视觉上矮一截。
解决方法：
立即学习“前端免费学习笔记（深入）”；
- 强制编号内嵌：
ol { list-style-position: inside; }，让编号参与li的盒模型，高度更可控 - 或彻底接管编号显示，用
::before+counter-increment替代原生序号，这样li就是纯内容容器，min-height表现最稳定 - 避免在
li内混用vertical-align: middle和inline-block元素——它们会拉高行框，使min-height实际生效高度大于预期
移动端ol li最小高度失效？重点查touch-action和font-size-adjust
iOS Safari 和部分安卓 WebView 对小字号 li 有隐式最小行高保护（尤其当 font-size ），这时设 <code>min-height: 24px 可能被覆盖。这不是 bug，而是可访问性机制：系统强制保障触摸热区 ≥ 44×44px，文字过小会自动撑开行高以满足点击面积。
应对策略：
- 不要硬压
font-size到 12px 还想靠min-height: 20px控制——直接放弃，改用font-size: 14px+min-height: 44px更稳妥 - 加
touch-action: manipulation到ol或li上，明确告诉浏览器“这是可点区域”，减少系统干预 - 慎用
font-size-adjust或text-size-adjust: none——它们可能绕过系统保护，导致 iOS 下点不中
用flex布局ol li时min-height为何不生效
把 ol 设为 display: flex; flex-direction: column 是常见做法，但此时 li 默认变成 flex-item，而 min-height 在 flex 容器中需配合 align-self: stretch 或显式 height: auto 才能正常响应。更隐蔽的问题是：flex 容器若没设 height 或 max-height，li 的 min-height 会被视为“最小内容高度”，而非“最小容器高度”。
关键点：
- 确保
ol有明确高度上下文（比如父容器设了height: 300px，或自身设max-height: 200px） -
li上写min-height: 48px; align-self: stretch;，比单写min-height更可靠 - 避免同时设
flex: 1和min-height——前者会抢占剩余空间，后者可能被忽略
真正要让每个 li 底线严格对齐，不能只盯 min-height；得连同编号定位、字体底线、flex 对齐模式、移动端热区规则一起调。漏掉任意一环，都可能在某个浏览器里“看起来没生效”。
