浏览器对非法 href 值静默降级为相对路径解析，如开头空格或零宽字符导致拼接出错并 404；href="" 刷新页面，href="#" 跳转顶部；base 标签叠加非法 href 会加剧路径错误；构建工具可能掩盖问题，需 html-validate 或 htmlproofer 提前检测。
浏览器直接忽略 href 值并静默降级为相对路径解析
当 <link> 的 href 属性值不符合 URL 语法（如缺少协议、含非法字符、以空格开头、混入零宽字符等），浏览器不会报错或警告，而是放弃将其当作绝对 URL 处理，转而按相对路径规则拼接——即以当前 HTML 页面的 URL 为基准，把整个无效字符串当作子路径追加。
例如页面位于 https://example.com/blog/post.html，而写了 <link rel="stylesheet" href=" css/style.css">（开头多一个空格），浏览器实际请求的是 https://example.com/blog/ css/style.css，结果必然是 404。这种错误在 Network 面板里表现为一个明显带空格或乱码的 Request URL。
- 常见非法值：开头含空格/
\u200B等控制字符、href="C:\assets\style.css"、href="关于我们.css"、href="https://site.com/style.css?theme=暗色"（中文未编码） - 验证方法：右键
<link>标签 → “Copy link address”，粘贴出来看是否是完整可访问的 URL - 零宽字符最难察觉：必须在 VS Code 等编辑器中开启「显示不可见字符」才能看到
\uFEFF或\u200B
href="" 或 href="#" 会触发页面刷新或跳转到顶部
href="" 不是“不加载”，而是让浏览器重新请求当前页面 URL，等效于刷新；href="#" 则强制滚动到页面顶部（如果页面没定义 id="top"，就只是跳到开头）。这两者都容易被误认为“链接失效”，实则是行为明确但非预期。
- 若想禁用链接又保留语义，应写
href="javascript:void(0)"并配合 JS 阻止默认行为 - 若需纯视觉占位（如菜单项当前页），用
aria-current="page"+ CSS 隐藏下划线，而非留空href - W3C Validator 会报
Bad value "#" for attribute "href"，提示这不是合法导航目标
base 标签存在时，非法 href 会叠加双重解析错误
一旦页面声明了 <base href="/subapp/">，所有相对路径都会先被 <base> 修正；但如果 href 值本身非法（比如 href=" /css/main.css" 开头有空格），浏览器会先忽略 <base>，再按当前页面 URL 拼接——导致路径计算完全失控。
立即学习“前端免费学习笔记（深入）”；
-
<base href="assets/">是无效写法，浏览器静默丢弃，<link href="style.css">仍按当前页 URL 解析 - 合法
<base>必须是绝对 URL（https://example.com/subapp/）或根相对路径（/subapp/），且结尾必须带/ - 部署到子目录时，只改
<base>不够，还需确保静态资源（CSS/JS/img）真放在对应物理路径下
构建工具环境下，非法 href 可能被掩盖但终将暴露
Webpack/Vite 等工具常自动重写 href，比如把 href="./style.css" 替换为带 hash 的文件名。但如果原始值是 href=" style.css"（带空格），工具可能无法识别为有效模块依赖，最终输出仍是非法字符串，上线后才在浏览器里 404。
- 构建日志一般不校验 href 合法性，需靠 html-validate 或自定义插件提前拦截
- Vite 中若配置了
base: "/my-app/"，但 HTML 里写href="css/app.css"，最终请求路径是/my-app/css/app.css—— 若服务器没把资源放对位置，就是 404 - CI/CD 流程中建议加入 htmlproofer 扫描，它用真实 HTTP 请求检测，不依赖构建逻辑
