浏览器扩展中的 CSS、Sass 与 Less

​

模板示例

​

content-sass

npx extension@latest create my-extension --template=content-sass

​

content-custom-font

npx extension@latest create my-extension --template=content-custom-font

​

CSS 能力

​

在哪里引用 CSS

• manifest.json（content_scripts[].css）
• HTML 文件（<link rel="stylesheet" href="...">）
• 脚本导入（import "./styles.css"，启用时也包括 Sass/Less）

​

CSS 支持

​

示例：manifest.json 中的 CSS

{
  "manifest_version": 3,
  "name": "My Extension",
  "version": "1.0.0",
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "css": ["./styles/content.css"],
      "js": ["./scripts/content.ts"]
    }
  ]
}

​

示例：扩展页面脚本中的 CSS

import "./styles/popup.scss";

​

按上下文的输出行为

​

开发期行为

• Content script 的 CSS 导入会参与 content script 的 HMR/重新挂载流程。
• Extension.js 会为只有 CSS 的 content script 入口添加一个开发期辅助脚本，使更新得以传播。
• 页面 CSS 遵循常规的页面 HMR 管线行为。
• 结构性的 manifest/content script 变更仍可能需要扩展完整重载或重启。

​

模块化与预处理器

• CSS 模块在扩展页面上下文中表现最好。
• 当你安装相关依赖时，Extension.js 会启用 Sass/Less 支持。
• 当 Extension.js 检测到项目中存在 PostCSS 配置，或者你显式配置时，会自动运行 PostCSS。

​

最佳实践

• 把 content script 样式有意识地限定作用范围，减少与宿主页面的冲突。
• 对扩展页面 UI，优先使用组件级的模块样式。
• 显式地维护预处理器和 PostCSS 配置，避免随时间发生非预期的构建行为变化。
• 在持续集成（CI）中校验 manifest 字段所引用的 CSS 路径。

​

下一步

• 在 dev 更新行为 中了解更新结果。
• 进一步了解 CSS 模块。
• 进一步了解 PostCSS 集成。