transform 旋转不改变盒模型空间是正常行为，因其仅作用于渲染层而非布局计算，元素的 margin box 和布局位置保持不变，需通过包裹容器、手动预留空间或 JS 动态干预等方案解决视觉与交互错位问题。
transform 旋转后盒模型空间不变是正常行为，不是 bug —— 它压根不参与布局计算，只改渲染层。 想靠 transform: rotate() 让周围元素“让位”或“自动撑开”，注定失败。必须换思路：要么手动预留空间，要么用 JS 动态干预，要么换技术栈。
为什么 rotate 后元素还占原来位置
浏览器把 transform 当作“画布操作”，不是“布局操作”。元素的 margin box（决定文档流占位的盒子）完全没变，offsetWidth、offsetHeight、getBoundingClientRect() 返回的仍是原始尺寸和坐标。视觉上转了 45°，但 DOM 布局树里它还在原地。
- 常见表现：
transform: rotate(30deg)的按钮盖住下方文字，hover 区域却在原位置才生效 - 内联元素（如
<span></span>）直接加rotate()常无效，因它没有独立盒模型边界 - 父容器高度塌陷：子元素仅靠
transform位移/旋转，不会撑开父级高度
如何让旋转后视觉与交互对齐
关键不是“阻止占位”，而是“补足错位”。最稳妥路径是包裹 + 显式控制：
- 给要旋转的元素套一层
<div> 或设 <code>display: inline-block，让它获得可测量的盒模型 - 包裹容器必须有明确尺寸（
width/height）或内容撑开，否则rotate可能无感 - 设
transform-origin: center，避免默认左上角导致“飞出可视区” - 用
margin或padding手动回收旋转后溢出的空白（例如顺时针转 45°，顶部多出空隙，就加负margin-top） - 写死宽高：算出旋转后外接矩形尺寸（如 100×100 正方形转 45°，需设
width: 142px; height: 142px），再内部居中旋转内容 - 用
zoom：它会缩放实际占用空间，但兼容性差、最小字号限制（如 Chrome 强制 ≥12px）且已非标准属性 - JS 动态测算：
element.getBoundingClientRect()获取旋转后真实视觉区域，再用element.style.width和element.style.height反向设置 - 换 SVG：
<g transform="rotate(45)"></g>中的旋转是布局计算的一部分，但仅限 SVG 上下文 -
position: absolute子元素的参考点不再是祖先relative元素，而是这个 transform 父容器 -
z-index只在该新堆叠上下文中有效，可能被同级未 transform 的兄弟元素遮挡 - 鼠标点击判断仍按原始矩形匹配，拖拽/碰撞检测需自行用
getBoundingClientRect()换算坐标
想让旋转真正影响布局，只能绕开 transform
transform 天然不改布局，硬要它“参与重排”，就得用替代方案：
立即学习“前端免费学习笔记（深入）”；
最容易被忽略的坑：子元素定位和点击区域
一旦父容器加了 transform，它就强制创建新包含块和堆叠上下文：
这些不是边缘 case，而是所有用了 transform 的复杂交互组件都会撞上的墙 —— 不提前意识到，调试时会花掉远超预期的时间。
