@mixin 更适合现代 CSS 架构；它支持参数、条件逻辑、@content 嵌套及动态生成，维护成本低且作用域清晰；@extend 虽编译紧凑但易致样式污染、调试困难、隐式依赖强，且无法响应动态需求。
Mixin 不一定“比” Extend 更好用，但当需要参数、条件逻辑或动态内容时，@mixin 是唯一可行的选择；而 @extend 编译后产生的选择器合并行为，在现代 CSS 架构（如 BEM、CSS-in-JS、原子化）中反而容易引发意料外的样式污染和维护风险。
编译后 CSS 体积和结构差异直接决定可维护性
这是最常被忽略的实际影响点。Mixin 每次 @include 都会复制一份样式规则，导致 CSS 体积略增；Extend 则把多个选择器拼到同一组声明块里，表面看更“紧凑”，但实际破坏了样式作用域边界。
-
@mixin button-base($color: #007bff)被调用 5 次 → 生成 5 组独立规则，每条都含完整声明，便于浏览器解析和 DevTools 定位 -
.btn-primary { @extend .button-base; }+.btn-secondary { @extend .button-base; }→ 编译后变成.button-base, .btn-primary, .btn-secondary { ... }，一旦.button-base类意外出现在 HTML 中，就会触发全局样式覆盖 - 如果
.button-base后续被删掉但没检查所有@extend引用点，编译仍通过，但 CSS 输出里会残留无意义的.button-base选择器
带参数或逻辑分支的场景下，@extend 根本无法工作
Extend 是静态的、无状态的继承机制，它不接受任何输入，也不能响应条件变化。只要需求里出现“根据不同主题/尺寸/状态生成不同值”，就必须用 @mixin。
-
@mixin padding-x($size)可以传sm、lg或具体数值，内部用@if分支计算；@extend连一个变量都接不住 -
@content允许在 mixin 内插入任意嵌套规则（比如媒体查询、伪类），而 Extend 只能继承已有选择器的扁平样式块 - 想实现「按钮在 hover 时加阴影，但禁用状态下不加」？Mixin 可封装为
@mixin btn-variant($hover: true)；Extend 没法表达这种开关逻辑
占位符 %placeholder 看似折中，但仍有隐藏陷阱
%placeholder 是 Extend 的变体，只在被 @extend 时才输出 CSS，解决了基类泄露问题，但它继承的仍是静态结构，且调试困难。
立即学习“前端免费学习笔记（深入）”；
- 定义
%flex-center { display: flex; justify-content: center; align-items: center; }，再用.card { @extend %flex-center; }—— 编译后该规则会和所有其他@extend %flex-center的选择器挤在同一行，DevTools 里点击任一实例，高亮的是整组选择器，无法快速定位是哪个组件触发的 - 占位符不能嵌套调用，也不能传参，复用粒度粗，容易造成“为改一处，被迫动全局”的连锁修改
- Webpack / Vite 的 CSS 提取插件（如
mini-css-extract-plugin）对 %placeholder 的处理不如@mixin稳定，某些 tree-shaking 场景下可能误删未显式调用的占位符
真正关键的不是“哪个更短”，而是“哪个让修改成本更低”。当你需要改一个边框圆角值，Mixin 只需改一处定义，所有调用自动更新；Extend 却要求你确认每个继承点是否仍适用、是否被其他模块间接影响——这种隐式依赖，才是大型项目中最难 debug 的部分。
