transform本质是渲染层视觉变换，不触发重排，不影响文档流、布局尺寸和兄弟元素位置；offsetWidth与getBoundingClientRect()返回未变换前的原始几何信息，点击热区、父容器高度等均按原始盒模型计算。
因为 transform 本质不是布局操作，而是渲染层的视觉变换——浏览器在 layout 阶段就已固定元素的 margin box（决定它在流中占多少位置），transform 只是在绘制阶段把那个“画布”挪一挪、转一转、缩一缩，不触发重排。
transform 不改 offsetWidth / getBoundingClientRect() 的原因
这两个 API 返回的是 layout 阶段计算出的原始几何信息，和渲染后长什么样无关。哪怕你加了 transform: rotate(45deg) scale(2)，element.offsetWidth 还是原来的值，getBoundingClientRect() 的 width、height、left、top 全部基于未变换前的盒模型。
- 这不是 bug，是 W3C 明确规定的：transform 属于「视觉呈现层操作」
- 想拿到旋转后的实际像素覆盖区域？得手动用三角函数换算，或依赖非标准的
element.getTransformedBoundingBox()（需 polyfill） - 用
scale()放大按钮后发现点击热区没变大？对，pointer-events仍按原始尺寸响应
为什么父容器 height: auto 不会被 transform 子元素撑开
父容器计算高度时只看子元素的 margin box 尺寸和流内位置，完全无视 transform 带来的视觉位移或缩放。子元素就算 transform: translateY(200px) 飞到屏幕外，父容器高度还是 0（如果没其他内容）。
- 常见表现：卡片用
transform: translateY(-10px)上浮做悬停效果，但下方文字依然紧贴原位置，没留空隙 - 解决路径只有三个：给父容器设固定
height或padding；让子元素用margin或真实内容撑高；或者干脆不用transform，改用top+position: relative（会参与布局）
transform-origin 和包含块的关系容易被忽略
transform-origin 只影响旋转/缩放的锚点，不改变元素自身的定位起点（即 offsetLeft、getBoundingClientRect().left 仍从原始左上角算起）。更关键的是：只要元素应用了非 none 的 transform，它就强制创建新包含块和新堆叠上下文。
立即学习“前端免费学习笔记（深入）”；
- 内部
position: absolute子元素会以它为定位参考，而不是最近的relative祖先 -
z-index只在该新上下文中有效，可能被同级未 transform 元素遮挡 - 如果父容器同时有
filter或opacity: 0.99，会悄悄关闭 3D 上下文（preserve-3d失效）
真正难处理的从来不是“怎么转”，而是“转完之后交互和布局怎么对齐”。浏览器不会帮你把旋转后的视觉区域映射回 DOM 坐标系，这部分必须自己补足——要么预留空间，要么用 JS 换算，要么换 SVG 或 canvas。硬要 transform 影响布局，等于在渲染管线里强行插队，代价远高于收益。
