会，修改width、height、padding、border、margin等几何属性会触发重排；box-sizing本身不触发重排但影响width/height解释；transform替代left/margin可避免重排；display切换引发重排+重绘+图层重建。
盒模型属性会触发重排（reflow）吗
会，但仅限部分属性。修改 width、height、padding、border、margin 这些直接影响元素几何尺寸的盒模型属性，浏览器必须重新计算该元素及其后代的布局位置和大小，从而触发重排。
而 background-color、opacity、transform 等不改变几何信息的属性，只触发重绘（repaint）或合成（composite），开销小得多。
-
box-sizing本身不触发重排，但它会影响后续对width/height的解释——比如设为border-box后改width，实际收缩的是content区域，仍需重排 - 用
transform: translateX(10px)替代left: 10px或margin-left: 10px，可避免重排，因为不改变文档流尺寸 - 频繁读取
offsetWidth、getBoundingClientRect()等布局信息，可能强制浏览器同步计算（forced synchronous layout），导致隐式重排，性能更差
display 属性切换对布局性能影响极大
改变 display 值（如从 none → block）不只是显示/隐藏，而是彻底移除或插入元素到渲染树中，必然触发重排 + 重绘 + 重建图层（layer）。
相比而言， visibility: hidden 保留占位、不触发布局变化；opacity: 0 加上 pointer-events: n 更接近“视觉隐藏”，且支持硬件加速。
-
display: none→display: flex：整个子树需重新解析盒模型、计算主轴/交叉轴尺寸、处理flex-wrap等，开销远高于单个元素的width变更 - 服务端渲染（SSR）后在客户端首次设置
display，容易引发“布局抖动”——尤其是多个组件同时挂载时 - 用 CSS 动画控制
display是无效的，浏览器会跳过过渡，直接切换，这也是它不适合做交互动画的根本原因
box-sizing: border-box 能提升性能吗
不能直接提升运行时性能，但它能显著降低因盒模型理解错误导致的意外重排。
开发者在 content-box 下修改 width 后又加 padding 或 border，常会误判最终尺寸，进而用 JS 动态调整（如反复读写 offsetWidth），形成重排链。而 border-box 让 width 始终等于总宽度，行为可预测，减少“补丁式修复”带来的布局副作用。
- 全局重置：
* { box-sizing: border-box; }是现代项目的标配，不是性能优化技巧，而是预防性工程实践 - 混合使用
content-box（如某些 UI 库的图标组件）与border-box容器时，子元素的width: 100%行为会不一致，可能引发隐式重排 - CSS-in-JS 库（如 Emotion）默认不注入全局
box-sizing，需手动配置 reset，否则容易漏掉
Flex/Grid 布局是否比 float/inline-block 更耗性能
首次计算开销略高，但长期更可控。Flex 和 Grid 是声明式布局，浏览器可在一次 layout pass 中批量求解约束；而 float 和 inline-block 依赖文档流顺序和浮动清除，易产生连锁重排（例如一个浮动元素高度变化，可能影响后续多行布局）。
不过，过度嵌套 Grid（如 grid-template-areas 多层嵌套）或滥用 fit-content / minmax(auto, 1fr) 等动态尺寸函数，会让布局引擎难以提前剪枝，增加 layout 时间。
- Chrome DevTools 的
Rendering面板勾选Layout Shift Regions，能直观看到哪些区域因 Flex/Grid 子项尺寸变化而重排 - 用
contain: layout包裹独立模块（如卡片列表），可隔离其内部重排，防止扩散到父容器 - Grid 的
auto-fit+minmax()在窗口 resize 时可能高频触发 layout，建议搭配resize节流或用@container查询替代
盒模型本身不是性能瓶颈，但它是所有布局计算的起点。真正拖慢页面的，是那些你以为“只是改个 padding”的操作，背后牵出了整棵渲染树的重新验证。写 CSS 时多想一层“这个改动会让浏览器重跑几轮 layout”，比背诵性能指标有用得多。
