外部CSS不生效首要原因是浏览器未识别为样式表：必须确保link标签含准确小写的rel="stylesheet"属性、置于head内、href路径正确（以HTML文件URL为基准），且服务器返回Content-Type为text/css；否则即使路径无误也静默失效。
外部 CSS 不生效，90% 是浏览器压根没把它当样式表处理——先确认 <link> 被识别，再查路径、顺序、响应头，别急着改选择器。
rel="stylesheet" 拼写或大小写错了
浏览器只认 rel="stylesheet" 这个精确值：全小写、无空格、无多余字符。写成 rel="sytlesheet"（多 y 少 t）、rel="StyleSheet"（首字母大写）、rel="style" 或漏掉整个 rel 属性，标签就退化为普通链接。
现象：<link> 在 Elements 面板里可见，Network 面板里看不到 CSS 请求，Styles 面板空白，控制台零报错。
- 在 VS Code 里输入
<link rel="，看自动补全是否给出stylesheet—— 没出现就说明配置或拼写有问题 - 检查引号是否为英文半角；
rel=stylesheet（无引号）在部分解析器中会失败，务必加引号 -
rel="stylesheet "（末尾有空格）也可能被某些环境静默忽略
href 路径算错了基准
href 的计算永远以当前 HTML 文件的 URL 为准，不是你编辑器里看到的目录结构，也不是服务器根路径。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
常见错误：index.html 在 /blog/article.html，却写 href="css/style.css" → 实际请求的是 /blog/css/style.css，而非你放 CSS 的 /css/style.css。
- 本地双击打开
file://协议时，相对路径可能被安全策略拦截；用vite preview或 Live Server 测试才可靠 - 临时改成根相对路径测试：
href="/css/style.css"，能生效就说明原相对路径层级错了 - 右键点击
<link>中的href值 → “Open in new tab”，看能否直接返回纯 CSS 文本（不是 404 或 HTML 页面） - 构建工具（如 Vite）中，
public/下文件走根路径，src/assets/下则经打包后路径变化，href必须匹配最终输出路径
link 标签没放在 head 里或被动态插入
<link rel="stylesheet"> 必须是 <head> 的直接子元素。放在 <body> 里，等于告诉浏览器：“先画页面，CSS 慢点来”——结果就是 FOUC（页面闪一下、文字跳位），IE6–8 更是直接忽略整条规则。
- 确认它没被包在
<script>、<meta>或其他标签内部 - CMS 或 JS 框架自动生成的页面，常把
<link>插进<body>，需手动调整模板或配置 SSR - 用 JS 动态创建并插入
<link>（比如document.head.appendChild(link)）会延迟加载，FOUC 不可避免；这不是优化，是把问题显性化 - 推荐顺序：
<title>→<link rel="stylesheet">→ 其他<script>
服务器返回的 Content-Type 不是 text/css
即使路径对、标签对、状态码是 200，如果响应头里 Content-Type 是 text/plain 或 application/octet-stream，现代浏览器会拒绝解析 CSS。
- 在 Network 面板点开 CSS 请求 → Headers → Response Headers → 查
content-type - Nginx/Apache 配置缺失 MIME 类型映射时容易出这个问题；静态服务如 Vite 默认正确，但自建服务需手动配
- 本地双击打开时，
file://协议下浏览器不发请求头，但部分内核仍依赖文件扩展名判断类型；确保 CSS 文件扩展名是.css（不是.CSS或.csss） - 文件编码不是 UTF-8 无 BOM 也会导致解析失败，尤其含中文注释时；用编辑器另存为 UTF-8 无 BOM 格式
最容易被忽略的其实是 rel 的严格性和 href 的基准逻辑——它们不报错，却让整个样式链静默断裂。Network 面板里那个 CSS 请求的状态码和响应头，比反复检查选择器优先级更值得先盯死。
