17370845950

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 里写十几个 —— 那会引入加载顺序、重复引入、遗漏更新等问题。推荐：

• 用 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 更易落地，也方便新成员快速理解上下文。