transform旋转后盒子仍占原来位置。它不改变文档流，仅视觉变换，margin box尺寸位置不变，父容器和兄弟元素无感知，不影响布局计算。
transform 旋转后盒子还占原来位置吗
占。transform 不影响文档流，旋转后的元素视觉上动了，但它的布局占位（即 margin box）完全没变，父容器和其他兄弟元素完全感知不到它转过——这是最常被误解的一点。
常见错误现象：transform: rotate(45deg) 后，发现后面的文字没跟着“让出空间”，甚至和旋转盒子重叠；或者用 position: absolute + transform 做动画时，父容器高度塌陷。
- 原因：
transform属于“渲染层变换”，只作用于合成层（compositing layer），不触发 layout（重排） - 对比：
left/top或margin改变会直接修改盒模型尺寸或位置，从而影响布局流 - 兼容性无坑：所有现代浏览器对
transform的这个行为一致，包括 Safari 15.4+ 和 Chrome 100+
想让旋转后“腾出空间”该怎么做
不能靠 transform，得靠改变盒模型本身。有三个实际可用路径：
- 用
width/height预留旋转后的最大外接矩形尺寸（例如正方形旋转 45°，需按对角线长度设宽高） - 用
aspect-ratio+padding-top技巧模拟固定宽高比容器，再在内部用transform旋转内容 - 改用
rotate()配合offset-path或 SVG<g transform="rotate()"—— 这些场景下旋转是布局计算的一部分，但仅限特定上下文
示例：一个 100×100 的按钮旋转 30°，若希望周围文字自动绕开，必须手动设 width: 115px; height: 115px;（≈100×cos30°+100×sin30°），否则纯靠 transform 永远不会生效。
立即学习“前端免费学习笔记（深入）”；
transform-origin 对布局空间有影响吗
没有。无论 transform-origin 设成 top left、center 还是 50px 20px，都不改变元素的 margin box 位置和尺寸。
容易踩的坑：
- 误以为设
transform-origin: bottom right就能让盒子“从右下角转”，结果发现它还是从原始左上角坐标开始占位，只是旋转中心变了 - 和
perspective混用时，transform-origin会影响 3D 视觉效果，但依然不影响布局流 - 如果同时用了
will-change: transform，浏览器可能提前创建独立图层，但这也不改变盒模型计算时机
真正影响布局的旋转替代方案
如果业务逻辑确实需要“旋转后重新参与布局”（比如响应式卡片翻转后撑开容器），只能放弃纯 CSS transform，转向以下方式：
- CSS 写死不同状态的宽高（配合
@media或:is(.rotated)类控制） - 用 JavaScript 测量旋转后
getBoundingClientRect()，再动态设置style.width/style.height - 改用 SVG：SVG 元素的
transform在某些模式下（如作为<svg>子元素且未设viewBox）会参与布局计算，但行为边界模糊，不推荐用于通用布局
关键提醒：CSS 的 transform 本质是“画布操作”，不是“布局操作”。指望它改变文档流，就像指望 filter: blur() 让文字变宽一样，方向就错了。
