chrome 49及更早版本中height: 100%失效，因blink内核不将flex: 1父容器识别为有高度参照物，需逐级显式设置height（如html, body { height: 100% }）或改用flex: 1配合固定高度。
老版本 Chrome（Chrome 49 及更早）中 Flex 布局的“渲染错误”，多数不是 bug，而是内核压根不按现代规范解析——height: 100% 失效、flex: 1 不拉伸、align-items: stretch 不起作用，本质是高度链断裂或层叠上下文失控，得从渲染前提反推修复。
Chrome 49 及更早：百分比高度为何算不出
这些版本的 Blink 内核不把 flex: 1 撑开的父容器识别为“有高度”的参照物，子元素写 height: 100% 就退化成 height: auto。DevTools 的 Computed → height 几乎总是 auto 或 0px。
- 必须逐级显式设
height：从html开始，html, body { height: 100% }+ 父容器height: 100vh或固定值（如height: 400px） -
min-height: 100vh无效——旧版不把它当有效高度基准 - 嵌套两层以上 Flex 时，每一层都要单独加
height，漏一层就整条链失效 - 如果父容器本身是 Flex 子项，别指望外层
flex: 1“透传”高度；必须在它自己这层加height
Chrome 21–28：-webkit-flex 前缀为何写了还不生效
这不是前缀漏了，而是底层限制：这些版本只认 display: -webkit-flex，且一旦父容器用了 float 或 position: absolute，整个声明就被丢弃。
- 所有 Flex 属性都得加前缀：
-webkit-flex-direction、-webkit-justify-content、-webkit-align-items；flex简写必须拆成-webkit-flex-grow、-webkit-flex-shrink、-webkit-flex-basis - 子元素禁用
vertical-align，否则会阻断 Flex 对齐逻辑 - 避免在
<table> 内部启用 Flex，旧版 WebView 对表格上下文支持极差 <li> <code>align-items: center在 Chrome 23 下对 inline 元素无效，需子项显式加display: block - 用 DevTools 的 Computed 面板检查目标元素是否标有 “Stacking Context” —— 若有，说明被祖先截断
- 临时注释掉所有疑似祖先的
transform、opacity、filter，再刷新验证 - 关键父容器要显式设
position: relative+z-index: 0（只写z-index无效） - 别在父级上滥用
transform: translateZ(0)做“性能优化”，旧版把它当层叠开关 - 删掉冗余中间层（如
.row、.content），改用gap或margin控制间距 -
align-items: stretch在深层嵌套中易引发连锁重排，对固定高区域（如头像）显式设align-self: flex-start -
contain: layout只对 Flex 直接子项有效，适合加在.card、.item这类语义块上，别加在容器本身 - 避免滥用
flex: 1，尤其在内容高度不可控的区域；优先用min-height或aspect-ratio
Chrome 56 及更早：z-index 错乱的根本原因
不是 z-index 数值不够大，而是 opacity: 0.99、transform: translateZ(0) 这类属性在旧版里强触发层叠上下文，把 z-index 锁死在局部范围内。
Flex 嵌套三层以上为何滚动卡顿
不是 JS 慢，而是 Chrome Layout 阶段真实超时：每层 display: flex 都要额外做主轴+交叉轴遍历，三层后常超 16ms/frame，触发 layout thrashing。
真正容易被忽略的是：这些“兼容性问题”背后，其实是不同 Blink 版本对 CSS 规范的实现差异——不是补几个前缀就能跑通，而是得先确认当前版本到底认不认那个属性、以什么方式认。调试时别只看本地开发环境，务必用真实旧版 Chrome（如 BrowserStack 或 Docker 镜像）验证，否则缓存或 HMR 会掩盖问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
