直接在Chrome DevTools的Network面板筛选CSS类型并刷新页面，若同一href地址（如/static/main.css）出现两次及以上请求，即存在重复加载；再结合Elements面板中Styles里带灰色删除线的规则，可快速定位重复引入与无效覆盖问题。
直接看 Network 面板里同一份 CSS 文件是否被加载多次，再结合 Elements 面板中样式规则的灰色划线状态，就能快速锁定重复引入 + 无效覆盖的问题。单纯扫文件或跑工具容易误判，关键得看运行时真实加载链路和生效逻辑。
怎么在 Chrome DevTools 里一眼识别重复加载
打开 DevTools → Network → 切换到 CSS 类型 → 刷新页面：
- 同一
href地址（比如/static/main.css）出现两次及以上请求，说明 HTML 或构建流程里写了多个<link> - 点开该 CSS 请求 → 查看 Initiator 列：能清楚看到是哪行 HTML、哪个 JS 脚本、或是哪个框架 API（如
import或useEffect）触发的加载 - 如果 Initiator 显示为
other，大概率是 HTML 中手动写的<link>；如果是webpack或vite，说明是构建工具自动注入的 - Elements 面板选中任意元素 → Styles 面板右侧列出所有匹配规则 → 凡是带灰色删除线的，就是被后加载的同名规则覆盖了，暗示顺序混乱或重复引入
为什么 PurgeCSS 扫不出“重复引入”的问题
PurgeCSS 的工作原理是字符串匹配：它只关心你在 content 配置里指定的文件中是否出现了某个类名，然后反向删掉 CSS 文件里没被“提到”的规则。它完全不感知 <link> 标签数量、加载时机或文件路径是否重复。
- 它不会告诉你
main.css被引入了两次，只会告诉你.btn-primary这个类有没有在 JS/HTML 里出现过 - 哪怕你把同一份 CSS 用
<link>引入三次，PurgeCSS输出的 CSS 文件体积也不会变大——因为它只处理源 CSS 内容，不处理 HTML 结构 - 真正要查“重复引入”，必须回到 HTML 源码、构建配置、框架模板三者交叉比对，而不是依赖静态分析工具
Webpack/Vite 项目里最容易漏掉的重复来源
现代构建工具让 CSS 引入变得隐式，反而更难排查：
立即学习“前端免费学习笔记（深入）”；
- Vite 中多个组件都写了
import './index.css'，且未配css.rollupOptions.inlineDynamicImports = false，会导致该 CSS 被内联多次 - Webpack 的
HtmlWebpackPlugin默认会自动注入打包后的 CSS，但你又在index.html里手动加了<link href="dist/main.css">，结果加载两遍 - Vue 单文件组件里用了
<style src="./base.css">，同时main.js又import '@/assets/css/main.css'，两个路径实际指向同一文件 - Next.js 的
app/layout.tsx和pages/_app.tsx同时 import 同一份全局样式，尤其在混合路由模式下极易发生
检查 HTML 源码时盯住这三个细节
右键 → “查看网页源代码”，搜索 <link rel="stylesheet"，重点关注：
- 相同
href值是否出现多次（注意路径是否等价，比如./style.css和/style.css在某些服务器上可能解析为同一文件） - 是否存在开发环境专用的
<link>（比如本地调试时加的 CDN 版 Tailwind），而构建产物里又保留了一份本地打包版 -
<link>标签是否被 JS 动态插入（搜document.createElement('link')或append(stylesheet)），这类运行时加载不会出现在源码里，但会在 Network 面板暴露
最常被忽略的是：你以为删掉了某处 <link>，但它其实藏在框架的默认模板、服务端渲染逻辑或 CI 构建脚本生成的 HTML 片段里。动手改之前，先确认那个 <link> 究竟是谁写的、在哪一层加的。
