绝对定位与flex布局性能无绝对优劣，关键取决于使用方式：绝对定位脱离文档流可减少重排，但频繁修改top/left会触发重排重绘，应改用transform；flex布局经现代浏览器优化，仅在属性变更时重排，但滥用flex-grow等动态值或强制同步layout（如读取offsettop后改样式）将导致性能下降。
绝对定位和Flex布局本身不直接决定性能高低，关键看你怎么用、用在什么场景、是否触发频繁重排（reflow）或重绘（repaint）。
绝对定位会强制脱离文档流，但不等于“性能差”
使用 position: absolute 的元素不再参与父容器的尺寸计算和布局流程，这反而能减少重排次数——尤其当它内部内容频繁变动、又不需要影响周围布局时。
- 常见错误：给绝对定位元素频繁修改
top/left值（比如做动画），每次都会触发重排+重绘，比用transform慢得多 - 正确做法：用
transform: translate()移动绝对定位元素，只触发合成层（compositor）更新，跳过重排重绘 - 兼容性注意：
will-change: transform或transform: translateZ(0)可提前创建合成层，但滥用会导致内存占用上升
Flex布局默认触发布局计算，但现代浏览器已高度优化
display: flex 会让父容器进入 Flex 布局算法，子项尺寸、顺序、对齐方式都要重新计算。但它只在初始渲染或显式改变相关属性（如 flex-direction、justify-content、子项 flex 值）时才触发重排。
- 高频陷阱：在滚动/动画中反复修改
flex-grow或flex-basis，等同于反复请求 layout，性能雪崩 - 安全操作：仅用
align-items/justify-content居中，或固定子项尺寸 +flex: 1分配剩余空间，几乎不增加重排开销 - 注意点：
flex-wrap: wrap在容器尺寸变化时可能引发多轮重排，尤其子项数量大时
真正影响性能的是“是否触发 layout 强制同步”
无论用绝对定位还是 Flex，只要代码中出现读取 offsetTop、clientWidth 等 layout 相关属性后立刻修改样式，就会强制浏览器同步执行重排（forced synchronous layout），这是页面卡顿最常见元凶。
- 典型错误模式：
el.offsetWidth; el.style.left = '100px'; - Flex 场景下更隐蔽：调用
getComputedStyle(el).flexGrow后立即改el.style.flexGrow - 检测手段：Chrome DevTools → Rendering → “Layout Shift Regions” 和 “FPS Meter”，配合 Performance 面板看 layout 时间占比
别迷信“绝对定位更快”或“Flex 更现代”，真正要盯住的是你改了哪些属性、是否在循环/事件中读写 layout、有没有意外触发合成层分裂。一个写死 top/left 的绝对定位弹窗，比一个每帧都 flex: calc(...) 的导航栏稳得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
