必须配合flex-basis重置与flex-shrink:0锁定，否则放大时会挤压兄弟元素或溢出容器；因transform不改变文档流尺寸，而flex布局依赖flex-basis和flex-shrink分配空间，未合理配置将导致空间争夺与布局错乱。
直接说结论：不能只靠 transform: scale()，必须配合 flex-basis 重置 + flex-shrink: 0 锁定收缩行为，否则放大时会挤压兄弟元素或溢出容器。
为什么 hover 放大后布局错乱或溢出
常见错误是给子项写 hover { transform: scale(1.2); }，看似放大了，但元素实际占据的空间（layout size）没变，只是视觉拉伸。如果父容器是 display: flex 且子项用了 flex: 1 或固定 flex-basis，放大后可能触发 flex-shrink 行为，导致兄弟项被压缩、换行，甚至整体撑破容器边界。
更隐蔽的问题是：当多个子项同时 hover（比如快速移入移出），transform 动画未结束时状态切换，浏览器来不及重排，造成抖动或宽度“跳变”。
- 子项默认
flex-shrink: 1，空间不足时会主动缩小 —— 这和你想要的“独占伸展”冲突 -
transform不影响文档流，但flex-basis和flex-grow才真正决定空间分配 - 未设置
overflow: hidden的父容器，放大后内容超出边界不可见，但 DOM 尺寸仍在
正确做法：用 flex-basis 切换“占用权”
核心思路是让未 hover 项“主动让出空间”，而不是靠放大项去“抢空间”。这需要放弃固定初始宽度，改用 flex-basis: 0 + flex-grow: 1 均分基础空间；hover 时改用绝对 flex-basis（如 40%），并禁用收缩。
立即学习“前端免费学习笔记（深入）”；
示例结构：
.list {
display: flex;
width: 100%;
}
.list > li {
flex: 1 0 0; /* flex-grow: 1, flex-shrink: 0, flex-basis: 0 */
transition: flex-basis 0.3s ease, transform 0.3s ease;
}
.list > li:hover {
flex-basis: 40%;
transform: scale(1.1);
}-
flex: 1 0 0等价于flex-grow: 1; flex-shrink: 0; flex-basis: 0—— 所有项初始不占固有宽度，仅靠 grow 均分 - hover 时
flex-basis: 40%生效，flex-grow自动失效，该项获得明确宽度 -
flex-shrink: 0防止其他项在空间紧张时被压缩到内容宽度以下（避免文字挤成一行）
容易忽略的兼容性与细节
某些旧版 Safari（iOS 12–13）对 flex-basis: 0% 解析异常，建议统一用无单位的 0 而非 0%；另外，transform: scale() 在部分安卓 WebView 中可能触发模糊，可加 will-change: transform; 提前提示渲染引擎。
- 父容器需设明确
width（如100%或具体像素），否则flex-basis: 40%计算失准 - 若子项含图片或字体，放大后可能因像素对齐问题出现轻微锯齿，可加
backface-visibility: hidden;缓解 - 移动端 hover 实际触发的是 touchstart，需额外测试 tap 交互是否符合预期
最麻烦的不是写对那几行 CSS，而是理解 flex 项的空间“所有权”如何随 flex-basis 和 flex-shrink 动态转移 —— hover 放大不是视觉特效，是一次空间重分配。
