transform缩放不改变文档流占位是规范行为：仅作用于渲染层，不影响布局计算；元素尺寸、父容器高度、相邻元素排列均按缩放前盒模型计算。
transform 缩放不改变文档流占位，是设计使然
这不是 bug，是规范明确的行为：transform 只作用于渲染层（painting layer），不影响布局计算（layout / reflow）。元素的 offsetWidth、getBoundingClientRect() 返回的仍是原始尺寸；父容器的自动高度、相邻元素的排列，全部按缩放前的盒模型来算。
常见错误现象：缩放后“悬空”或“覆盖错位”
加了 transform: scale(1.5)，元素视觉变大，但下方内容没被顶下去——说明它没占新空间；更糟的是，它可能盖住下面的按钮，而点击区域还在原位置（视觉和交互错位）。
- 元素缩放后边缘“突兀跳动”，常因
transform-origin默认值在左上角，又没显式设为center - 父容器设了
overflow: hidden，缩放后超出部分直接被裁，不是缩放失效，是渲染被截断 - 用 JS 读取
element.style.width或clientWidth判断缩放后尺寸？结果永远是原始值，得靠getBoundingClientRect()+ 手动乘缩放比
scale 和 width/height 的关键区别在哪
width/height 改变盒模型本身，触发重排（reflow），影响整个页面布局树；transform: scale() 只触发重绘（repaint），性能好，但副作用明显：
- 子元素的
font-size、border-width、box-shadow全部等比缩放，而width不影响这些 - 缩放后文字/图标易模糊，尤其非整数比（如
scale(1.3)），可加will-change: transform提示 GPU 加速 - 若需保持子元素尺寸不变，别用
scale，改用width/height+transform: scale()反向抵消（例如父层scale(2)，子层scale(0.5)）
想让缩放影响布局，就得绕开 transform
真要让缩放后元素“推挤”其他内容，就别用 transform。可行路径只有两条：
立即学习“前端免费学习笔记（深入）”；
- 用
width/height+padding动态调整，配合transition实现平滑变化（注意会触发重排） - 用 CSS 自定义属性 +
calc()模拟缩放效果，例如width: calc(var(--scale) * 200px)，再用 JS 控制--scale - 极少数场景可用
zoom（仅 Chrome/Edge 支持，且会破坏position: fixed行为，不推荐）
真正难的不是怎么缩放，而是判断该不该用 transform —— 它天生就和文档流“脱钩”，强行让它参与布局，只会不断打补丁。
