CSS引入失败需四步排查：路径是否正确（优先绝对路径）、Network中状态码与Content-Type是否为200/text/css、link是否在head中且未被JS移除、选择器是否匹配或被覆盖。
检查 link 标签的 href 路径是否真实可访问
浏览器不报错，不代表 CSS 文件被成功加载——它可能 404 了但被静默忽略。打开「Network」面板，筛选 css，看对应文件状态码是不是 404 或 200。常见坑：href 写成相对路径却没注意当前 HTML 所在目录层级，比如 HTML 在 /admin/index.html，而写了 href="style.css"，实际会请求 /admin/style.css，而非项目根目录下的 /style.css。
- 用浏览器地址栏直接访问
href的完整 URL（如http://localhost:3000/css/style.css），确认能下载到内容 - 优先用绝对路径：以
/开头（如href="/css/style.css"），避免路径计算歧义 - 若用构建工具（Vite / Webpack），确认该 CSS 文件是否被纳入打包/复制流程，静态资源未配置
public目录或assets规则时容易漏掉
确认 link 标签是否被写在
CSS 必须在 中声明才有效；如果误写在 底部，部分浏览器虽会尝试加载，但样式可能不生效或触发 FOUC。更隐蔽的是：某些初始化脚本（如 UI 框架、A/B 测试 SDK）会在 DOM 加载后遍历并清理“未知” link 标签。
- 用 Elements 面板搜索
，确认标签确实存在于 DOM 中且未被display: none或disabled属性禁用 - 检查是否有 JS 执行了类似
document.querySelector('link[href="xxx"]').remove()或设置了link.disabled = true - 临时禁用所有第三方脚本（DevTools → Application → Service Workers → Unregister，或勾选「Disable JavaScript」测试），排除干扰
验证 CSS 文件内容是否被正确解析（MIME 类型与编码）
即使 HTTP 状态是 200，服务器返回的 Content-Type 错了（比如返回 text/plain 而非 text/css），Chrome 等浏览器会拒绝解析样式——但不会抛错误，只在 Network 面板的「Type」列显示 txt 或 document，且 Styles 面板里完全看不到该文件。
- 在 Network 面板点开 CSS 请求 → Headers → Response Headers → 查看
Content-Type是否为text/css - 用
curl -I http://localhost:3000/style.css快速验证响应头 - 本地开发时，若用 Python
http.server或某些轻量服务器，默认不设 CSS MIME 类型，需手动配置或换用支持静态资源的 dev server（如 Vite 的vite preview） - 文件含 BOM 或编码为
UTF-16也可能导致解析失败，用编辑器另存为UTF-8 without BOM
排查 CSS 本身是否「空生效」：选择器失效或权重被覆盖
文件加载成功、控制台无报错，但页面没变化？大概率是样式写错了，而不是引入失败。这类问题最易误判为「引入失败」。
立即学习“前端免费学习笔记（深入）”；
- 打开 Elements 面板，选中目标元素，看右侧 Styles 面板是否列出你的 CSS 文件；如果没有，说明该规则根本没匹配上
- 检查选择器拼写（
.btn-primaryvs.btn-prmiary）、大小写（类名区分大小写）、层级（div .item不匹配）- 用
!important临时测试：在开发者工具中手动加一条带!important的声明，若生效，说明原规则被更高权重覆盖（如内联样式、ID 选择器、后加载的 CSS）/* 示例：这种写法在 HTML 中不会生效，因为 .container 是类，不是标签 */ container { color: red; }/ 正确应为 / .container { color: red; }
真正难查的不是报错，而是「什么都没发生」——路径、网络、MIME、选择器，四层都得手动过一遍，缺一不可。
- 用
