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(仅定义:rootCSS 变量或极少数全局 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 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/ 变成全局变量垃圾场。前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










