不能只靠 transition + width 实现搜索框伸缩，因会导致内容裁切、焦点丢失或 display: none 下动画失效；应使用 Less 混合器按状态参数封装尺寸、边距等样式，确保编译期计算、结构清晰、响应式解耦。
搜索框伸缩为什么不能只靠 transition + width？
直接对 width 做 CSS transition 会导致收缩时内容被裁切、焦点丢失，或在 display: none 切换时动画完全失效。Less 本身不执行动画，但能帮你把「展开态」「收起态」「聚焦态」的样式逻辑拆清楚，避免状态耦合。关键不是“用 Less 写动画”，而是用混合器（.mixin）把不同状态下的尺寸、边距、透明度、可见性组合封装好，让调用处干净且可预测。
如何用 Less 混合器统一管理 focus / active / collapsed 状态？
别把所有状态写死在选择器里。用带参数的混合器按需注入样式块，比如：
.search-box-states(@is-expanded: false, @is-focused: false) {
width: if(@is-expanded, 240px, 48px);
padding-inline: if(@is-expanded, 12px, 0);
border-radius: if(@is-expanded, 6px, 50%);
&::placeholder {
opacity: if(@is-expanded, 1, 0);
}
&:focus-within {
width: 240px;
padding-inline: 12px;
}
}
这样调用：.search-box-states(true, true) 就能生成展开+聚焦的样式；而基础选择器只需一次引用，后续增删状态不改结构。注意：Less 的 if() 是编译期计算，不会产生运行时开销。
伸缩动画卡顿或跳变的三个常见 Less 相关原因
动画不顺滑，往往不是 CSS 属性问题，而是 Less 编译后样式优先级或覆盖逻辑出错：
-
transition必须写在基础选择器上（如.search-input），不能只写在混合器内——否则不同状态注入的transition可能相互覆盖 - 用
max-width替代width实现伸缩更安全，但 Less 中若混用width和max-width混合器参数，容易漏掉某条路径的重置（比如收起时没设max-width: 0） - 如果用了
:has()检测父容器状态，Less 编译后可能生成冗余选择器链，导致浏览器重排压力增大——建议只在必要时用，且避免嵌套三层以上
移动端点击放大、键盘弹起时搜索框错位怎么办？
这不是 Less 能解决的问题，但 Less 结构会影响你修复它的效率。重点在于把「响应式断点」和「交互态」解耦：
用独立变量控制尺寸基准：@search-base-width: 48px;，再通过 @media (min-width: 768px) 覆盖为 64px；而伸缩逻辑仍走同一套混合器。这样当 iOS 键盘弹出导致视口高度变化时，你只需要检查 position: fixed 或 transform: scale() 是否干扰了 width 计算，而不是翻遍所有 Less 文件找硬编码的像素值。
真正容易被忽略的是：混合器里写的 height 或 line-height 如果没随 font-size 动态缩放，在 viewport 缩放后会失准——建议全部用 em 或 rem，别用 px。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
