display: inline-block在safari和firefox中vertical-align表现不一致，因二者对基线判定逻辑不同：safari依第一行文本baseline，firefox依元素box底部；显式设vertical-align: top或改用flex+align-items: center更可靠。
CSS2.1 规范早已稳定，但“写法能用”不等于“行为一致”。现代浏览器对 CSS2.1 的实现并非完全统一，尤其在默认值、继承逻辑、盒模型解析和渲染边界上仍有隐性差异。
为什么 display: inline-block 在 Safari 和 Firefox 中 vertical-align 表现不一致
这不是语法错误，而是渲染引擎对基线（baseline）的判定逻辑不同：Safari 依据第一行文本内容的 baseline，Firefox 可能依据元素自身 box 的底部。即使都支持 inline-block，vertical-align: middle 的实际对齐位置仍可能偏移 1–2px。
- 避免依赖默认基线：显式设置
vertical-align: top或vertical-align: -4px（需实测） - 更可靠方案：改用
flex容器 +align-items: center，绕过 inline-block 的基线歧义 - 若必须用 inline-block，给父容器加
font-size: 0消除空白符影响，子元素再重设 font-size
min-height 在 Chrome 128+ 和 Edge 127 中触发 hasLayout 的条件变了
旧版 IE 的 hasLayout 是私有概念，但现代 Blink/EdgeHTML 内核仍保留类似机制——某些 CSS 属性组合（如 min-height + overflow: hidden）会隐式触发 BFC，而另一些组合（min-height + position: relative）在新版中不再触发，导致浮动清除失效或 margin collapse 恢复。
- 不要假设
min-height必然创建新 BFC；验证方式是看父容器是否包裹了浮动子元素 - 需要强制 BFC 时，优先用标准属性：
display: flow-root（Chrome 64+/Firefox 67+），比overflow: hidden更语义清晰且无副作用 - 若需兼容 Safari 15.6 以下，
display: flex或display: grid是更稳妥的替代
table-layout: fixed 下单元格宽度计算在 Firefox 120 和 Chrome 中结果不同
当 <col> 标签缺失、且首行 <td> 含长文本时，Firefox 会按内容撑开列宽，Chrome 则严格按 <code>width 属性截断并换行——两者都符合 CSS2.1 文本，但对“内容优先”还是“样式优先”的权衡不同。
- 必须精确控制列宽时，显式写
<col width="200">，而非只靠td { width: 200px } - 避免在
table-layout: fixed中混用max-width或white-space: nowrap，这些组合在各引擎中未定义行为 - 移动端 WebView（如 iOS 17 UIWebView）对此更敏感，建议用
display: grid重构表格型布局
CSS2.1 代码，却各自交出不同的视觉答卷——这时候查 caniuse 没用，得打开 DevTools 对比 computed styles 里的 actual value，再看 layout panel 是否触发了预期的 formatting context。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
