link标签href值必须是有效URL，优先用根相对路径如"/css/style.css"；避免query参数影响缓存，应通过文件名版本控制；禁用protocol-relative URL；确保路径大小写和扩展名完全匹配；务必用Network面板验证200响应。
link 标签 href 值必须是有效 URL，相对路径容易出错
href 属性不是“填个文件名就行”，它必须解析为浏览器能获取的资源地址。常见错误是写成 href="css/style.css" 却没注意当前 HTML 文件所在路径——如果 HTML 在 /admin/index.html，而 CSS 在 /css/style.css，那这个相对路径实际会请求 /admin/css/style.css，404 就发生了。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 优先用以
/开头的根相对路径（如href="/css/style.css"），避免依赖 HTML 位置 - 开发时打开浏览器开发者工具的 Network 面板，直接看
link请求是否返回 200 - 不要在 href 里拼接变量或用 JS 动态改 href——CSS 加载是阻塞的，时机难控，也绕过预加载
href 中的查询参数会影响缓存和 HTTP 请求行为
加 ?v=1.2.3 或 ?t=1715829300 看似是“刷新缓存”的惯用法，但它会让每次变更都触发全新请求，可能破坏 CDN 缓存、增加服务器压力，甚至干扰 HTTP/2 的多路复用效率。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 版本控制应走文件名（如
style.v1.2.3.css），而非 query 参数；构建工具（Vite、Webpack）默认支持 - 开发环境可加
?_t=Date.now()用于调试，但构建后必须移除 - 若服务端强制 no-cache，query 参数无效，此时应检查响应头中的
Cache-Control
不支持 protocol-relative URL（//example.com/style.css）的现代场景
这种写法曾用来适配 HTTP/HTTPS 混合环境，但现在几乎没意义：HTTP 站点已普遍被浏览器标记为不安全，且本地开发用 file:// 协议时，// 会直接失败（报 Not allowed to load local resource）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 一律用明确协议，如
href="https://cdn.example.com/style.css" - 内网或私有部署时，用根相对路径
/static/css/style.css更稳妥 - 避免在 href 中写
http://——除非你确定目标站点不支持 HTTPS，否则会触发混合内容警告
link 标签的 href 不会自动补全扩展名或重定向
写成 href="/css/main" 并不会自动尝试 /css/main.css 或跟随服务端 301 重定向——浏览器只按字面发起一次 GET 请求，404 就是 404，不会“猜”。Nginx/Apache 的 try_files 或 FallbackResource 对 link 无效。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 确保 href 的值与文件系统或 CDN 上的真实路径、大小写、扩展名完全一致（Linux 区分大小写！）
- 用
curl -I或浏览器直接访问 href 地址，确认返回 200 + 正确Content-Type: text/css - 构建产物中检查
dist/目录结构，别依赖开发服务器的“友好重写”
最常被忽略的一点：CSS 加载失败时页面通常无任何提示，只有样式缺失。不能只靠肉眼判断，必须查 Network 面板里的 status 和 Initiator 列——很多“样式没生效”问题，根源其实是 link 根本没加载成功。
