content_scripts 的 css 字段需在数组项中直接声明为字符串数组，路径相对于 manifest.json，仅支持扩展内本地文件，按数组顺序注入且后加载的样式优先级更高。
content_scripts 的 css 字段到底怎么写
直接在 content_scripts 数组项里填 css 字段就行，路径是相对于 manifest.json 所在目录的相对路径。它和 js 是同级字段，不是子属性，也不是嵌套在某个对象里。
-
css值必须是字符串数组，哪怕只引入一个 CSS 文件也要写成["styles.css"]，不能写成"styles.css" - 路径不支持绝对路径或 URL，只能是扩展包内的本地文件，比如
["css/main.css", "node_modules/normalize.css"]（后者需确保该文件实际存在于打包目录中） - 多个 CSS 文件按数组顺序注入，后面的规则会覆盖前面的同名选择器——这点和页面中
<link>的加载顺序一致
为什么加了 css 字段但样式没生效
常见原因不是语法错，而是作用域或时机问题。CSS 注入后默认就生效，不需要手动触发，但以下情况会导致“看不见效果”：
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 选择器被页面原有样式权重压制：比如你写了
body { background: red }，但页面用了body#app.main-page { background: white !important }，你的规则就输了 - CSS 文件路径 404：Chrome 不报错，但控制台 → Application → Manifest → content_scripts 展开能看到实际匹配到的资源列表，点进去看是否显示 “Not found”
- 匹配规则没命中：检查
matches是否覆盖目标页面，比如写成了"matches": ["https://example.com/*"]却去访问http://example.com（协议不匹配） - 样式被 Shadow DOM 隔离：如果目标元素在自定义组件的 Shadow Root 内，普通 CSS 无法穿透，得用
:host或::slotted等影子选择器，或改用 JS 动态注入到 shadowRoot.style
css 和 js 的注入顺序与执行时机差异
css 和 js 虽然写在同一项里，但行为完全不同：CSS 是立即注入并解析的，JS 则受 run_at 控制。这意味着即使你设了 "run_at": "document_start"，CSS 也早在 DOM 构建前就已生效。
- 如果你在
content.js里用document.body.classList.add("my-theme")来切换主题，对应的 CSS 必须提前注入（靠css字段），否则 class 加上了但没样式 - 反过来，如果 CSS 依赖 JS 创建的 DOM 节点（比如给 JS 动态插入的
<div class="tooltip"> 写样式），那没问题——CSS 是全局的，只要节点存在且 class 匹配就会生效 <li>没有 <code>run_at对 CSS 生效时机的影响，css字段不认这个参数 - Manifest V3 中仍可继续用
content_scripts.css，无需额外权限，也不需要 runtime 请求 -
chrome.scripting.insertCSS适合运行时条件判断后才决定是否注入（比如仅对含视频的页面加播放器样式），但它要求先申请"scripting"权限，且只能在 service worker 或 popup/background 中调用，不能在 content script 自己调用 - 二者不互斥，可以静态注入基础样式 + 动态注入增强样式，但注意避免重复或冲突
动态注入 CSS 时为什么不能用 chrome.scripting.insertCSS
这是个容易混淆的点：chrome.scripting.insertCSS 是 Manifest V3 的 API，只在具备 "scripting" 权限且通过 chrome.scripting.executeScript 或事件触发时才可用；而 content_scripts.css 是 Manifest V2/V3 都支持的静态声明式注入，走的是完全不同的机制。
