base目录只放重置和根级变量，utils只存变量、mixin、函数且不输出样式；二者混用会导致重编译失控、逻辑越界和选择器污染。

base 目录必须放重置和根级变量，utils（或 abstracts）只存变量、mixin、函数——不写一行样式。错放文件比目录少一个更致命。

为什么 base 和 utils 必须严格分离

很多团队把字体、颜色、断点全塞进 _base.scss，结果改个 font-size 就触发全量重编译；更糟的是，有人在 utils/_mixins.scss 里直接写 @mixin card-shadow，这已经越界到组件逻辑了。

• base/ 是“基础设施层”：只含 _reset.scss、_typography.scss、_variables.scss（仅定义 :root CSS 变量或极少数全局 Sass 变量），禁止出现任何业务 class 名
• utils/（或 abstracts/）是“工具层”：只放 _variables.scss（主题色 map、断点 map）、_mixins.scss（如 @mixin respond-to($bp)）、_functions.scss（如 @function em($px)），它不生成任何 CSS 输出
• 常见错误现象：components/_button.scss 里 @import '../../utils/mixins' 成功，但 pages/dashboard.scss 直接 @import 'utils/mixins' 却报 Undefined mixin——因为入口文件没按依赖顺序导入 utils

components/ 文件粒度怎么拿捏

一个 _card.scss 文件应该对应视觉上可独立存在的 UI 单元，不是按“功能模块”切分，而是按“是否能单独截图发给设计师确认”。文件内禁止跨组件引用，也不该依赖 pages/ 下的任何东西。

PigX UI 前端开发

PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。

下载

• 每个组件文件只负责自己：结构（用 BEM 命名）、状态（&.is-loading）、响应式（@include respond-to(md)）
• 避免深层嵌套：.card { .card__header { &__title { } } } 编译后选择器权重高、难覆盖；改成 .card__title 平铺写法更可控
• 禁止在组件里用 !important——靠引入顺序和选择器简洁性解决覆盖问题，否则 pages/home.scss 想覆盖 .card 圆角都得加权重 hack

为什么 pages/ 必须放在 @import 链末端

pages/ 不提供基础能力，只做页面级覆盖。如果它被提前导入，就会污染 components/ 的默认行为，比如让所有按钮默认带阴影——这不是复用，是失控。

• main.scss 的导入顺序必须是：@import 'base/index'; @import 'utils/index'; @import 'components/index'; @import 'layout/index'; @import 'pages/index';
• 业务文件（如 pages/product.scss）永远只 @import '../index'，绝不直接 @import 'components/button'——否则重构 components/ 路径时，散落各处的导入会集体失效
• 典型问题：pages/dashboard.scss 里写了 .dashboard-card { @extend %card-base }，但 %card-base 在 components/_card.scss 里——@extend 跨模块极易引发选择器爆炸，CI 应禁用此类写法

真正卡住维护节奏的，从来不是目录数量，而是哪个文件该写什么、不该写什么——边界模糊时，components/ 会偷偷塞进布局逻辑，pages/ 开始复用样式，utils/ 变成全局变量垃圾场。