浏览器实际请求的URL是开发者工具Network中红色style.css请求的Request URL；它由HTML页面URL和link标签href属性共同决定，而非文件系统路径，需结合服务器配置、构建工具base设置及缓存策略综合排查。
确认浏览器实际请求的 URL 是什么
浏览器根本不管你的本意，只认它拼出来的地址。打开开发者工具（F12）→ Network 标签页，刷新页面，找到那个红色的 style.css 请求，点开看 “Request URL”。这个地址就是真实发出的请求路径——如果它和你预期的文件位置对不上，问题就出在路径计算上。
常见错位现象：
-
href="css/style.css"在/blog/post.html中，实际请求的是https://example.com/blog/css/style.css（不是你项目根下的/css/） -
href="/css/style.css"却 404，说明服务器上/css/style.css这个物理路径根本不存在（比如构建后 CSS 被输出到了/assets/css/） - 本地双击打开 HTML 文件时，
file://协议下/会指向磁盘根（如C:/），不是项目根目录
检查 <link> 标签是否写对了
rel="stylesheet" 必须严格满足：全小写、无空格、不能漏掉。漏写或拼错（比如写成 rel="StyleSheeT"、rel="css" 或 rel="stylesheet "）会导致浏览器压根不把它当样式表处理——不发请求、不报错、Elements 面板里能看到标签，但 Styles 面板永远为空。
type="text/css" 已完全冗余，删掉更干净；href 值中避免中文、空格、反斜杠（\），统一用正斜杠（/）。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
路径基准永远是 HTML 页面的 URL，不是文件系统位置
相对路径（如 ./css/style.css、../assets/style.css）始终以当前 HTML 页面的完整 URL 为起点计算，而不是你在编辑器里看到的文件夹结构，也不是 CSS 文件自身所在位置。
举例：页面 URL 是 https://example.com/blog/article.html
-
href="style.css"→ 请求https://example.com/blog/style.css -
href="../css/style.css"→ 请求https://example.com/css/style.css -
href="/css/style.css"→ 请求https://example.com/css/style.css（从域名根开始）
绝对路径（以 / 开头）依赖服务器配置，开发时务必用本地 HTTP 服务（如 python -m http.server、VS Code Live Server 或 vite preview）启动，不能双击打开 HTML 文件。
后端框架场景下别忘了静态文件服务配置
Django、Flask 等框架默认不自动提供静态资源服务，404 很可能是因为路由没配好，不是路径写错了。
- Django：确保
settings.py中定义了STATIC_URL和STATICFILES_DIRS，并在主urls.py中添加static(settings.STATIC_URL, document_root=settings.STATIC_ROOT) - Flask：静态文件夹名必须是
static；推荐用{{ url_for('static', filename='css/style.css') }}生成路径，而非硬编码href - Webpack/Vite 等构建工具：检查
publicPath或base配置是否与部署路径一致，否则/开头的路径会指向错误的根
缓存常掩盖路径修正效果，调试时请强制刷新（Ctrl+F5）或在 DevTools → Network 中勾选 “Disable cache”。
