transform缩放不改变文档流尺寸是设计使然，它仅修改渲染坐标、绕过布局计算，故offsetWidth等属性不变，且事件坐标与视觉位置脱钩。
因为 transform 是纯视觉层操作，它根本不会触发浏览器的布局（Layout）计算阶段。
transform 缩放不参与 layout 计算
浏览器渲染分三步：Layout → Paint → Composite。transform 属于最后一步 Composite，只改绘制坐标，不动 DOM 盒模型。所以 offsetWidth、getBoundingClientRect()、父容器高度、兄弟元素排布——全都不变。
你看到的“变小了”，只是 GPU 把那一块像素压缩画出来了；DOM 里那个盒子还是原来那么大、那么重、那么占位。
- 常见错误：给
transform: scale(0.5)的按钮加margin: -25px手动“回收空白”，结果在响应式下错位或溢出 - 更糟的是：用
width: 50%配合scale(2)想“视觉放大但保持占位”，实际是双倍尺寸+双倍缩放，完全失控 - 真正影响 layout 的缩放属性只有
zoom（非标准）、font-size（仅对 em/rem 内容有效）、或显式设width/height
为什么 getComputedStyle(el).transform 解析出的 a/d 值不能直接当缩放比？
矩阵里的 a 和 d 是变换矩阵的线性分量，但它们混着 rotate、skew、translate 等干扰项。比如 rotate(90deg) scale(1) 下，a 可能是 0，d 也可能是 0，但缩放比仍是 1。
立即学习“前端免费学习笔记（深入）”；
必须用向量模长公式还原：
- X 方向真实缩放 =
Math.sqrt(a * a + b * b) - Y 方向真实缩放 =
Math.sqrt(c * c + d * d) - 忽略
e和f（它们是 translate 分量，不参与缩放）
缩放后点击区域错位，不是 bug，是坐标系没对齐
鼠标事件的 clientX/clientY 基于原始 layout box 计算，而视觉内容已被缩放。一个 width: 200px 的按钮加了 scale(0.5)，视觉宽只剩 100px，但点击 (180, 50) 依然命中——因为那还在它原来的 200px 区域内。
- 修复方式只有两种：
不用 scale（改用width+font-size），或手动换算坐标（读取缩放比 +transform-origin偏移，反向映射） -
pointer-events: none或overflow: hidden完全无效，它们不改 hit-testing 底层逻辑 - 如果用了
transform-origin: top left，换算时原点偏移就是 0；若为center，就得减去一半宽高再除以缩放比
最常被忽略的一点：只要父元素加了任何非 none 的 transform，它就强制创建新包含块和堆叠上下文——子元素的 position: absolute 定位参考系、z-index 作用域、甚至 getBoundingClientRect() 返回值，全都变了，且无法用纯 CSS 恢复。
