css应按业务模块而非技术类型拆分，如product-detail.css、user-profile.css；组件样式内聚于单文件，用构建工具自动聚合，辅以命名约束和注释说明。
把 CSS 按功能或页面模块拆分成多个文件，是提升可维护性的有效方式，关键不在“拆”，而在“怎么拆”和“怎么管”。
按业务模块组织，而不是按技术类型
别再写 base.css、layout.css、theme.css 这种泛泛而分的文件——它们容易重叠、职责不清。优先按实际业务单元来切，比如：
- product-detail.css：商品详情页所有样式（含轮播、规格选择、评论区）
- user-profile.css：个人中心页的头像上传、信息编辑、安全设置等区块
- cart-summary.css：购物车右上角悬浮面板、结算弹窗等复用性较高的组件样式
这样改需求时，开发能快速定位到对应文件，不会在十几个通用文件里来回跳转找样式。
组件级样式尽量内聚，避免跨文件依赖
一个组件的结构、样式、行为尽量收在一个地方。例如写一个带展开/收起的 FAQ 卡片：
立即学习“前端免费学习笔记（深入）”；
- HTML 结构中明确 class 命名前缀，如
faq-item、faq-item__header - 所有相关样式写在
faq.css里，不分散到common.css或utils.css - 如果用了 BEM，就在该文件内完整实现，不靠外部基础类“拼凑”
减少隐式依赖，删掉一个模块时，连带删掉对应 CSS 文件也不会影响其他页面。
用构建工具自动聚合，不手动 link 多个 link 标签
拆完文件后，别在 HTML 里写十几个 <link rel="stylesheet"> —— 那会引入加载顺序、重复引入、遗漏更新等问题。推荐：
- 用 PostCSS +
postcss-import在开发期合并，最终只输出一个 CSS 文件 - 用 Webpack 的
mini-css-extract-plugin按入口或异步 chunk 自动分包（比如首页加载home.css，后台页加载admin.css） - 服务端渲染项目可用 CSS-in-JS 方案（如 Linaria）或 CSS Modules，天然隔离作用域
拆是为了逻辑清晰，合是为了运行高效——拆与合由工具链完成，人只关心模块边界。
加轻量级命名约束，不靠文档靠代码自解释
每个模块 CSS 文件开头加一段注释说明适用范围和注意事项，例如：
// user-profile.css
// - 仅用于 /user/profile 路由下的 DOM
// - 所有 class 必须以 'up-' 开头（up-avatar, up-form-group）
// - 不得使用 ID 选择器或全局标签样式（如 button {}）
// - 修改前需同步检查 user-settings.css 中的复用逻辑这种小约定比写 Wiki 更易落地，也方便新成员快速理解上下文。
