超链接报404主因是浏览器发出的请求路径与服务器真实文件路径不匹配,须通过Network面板查看Request URL并比对修正;状态码为0则多因跨域或file://协议限制,与拼写无关。

超链接报404,八成不是链接“写错了”,而是浏览器拼出来的请求路径和服务器上真实存在的文件路径没对上——得从 Network 面板里揪出那个被发出去的 URL,再一一对齐。
怎么看浏览器实际发了什么请求
别信地址栏、别猜 href 里写了啥,F12 → Network → 勾选 Preserve log → 点击链接 → 找红色标出的 404 条目。点开它,在 Headers 标签页看 Request URL 字段。
- 这个 URL 是服务器真正收到的,也是你要修复的靶心
- 如果显示
http://localhost/blog/post.html,但你文件实际在posts/blog.html,那就得改 HTML 或移动文件 - 状态码是
0?大概率是跨域、file://协议或连接被主动关闭,和拼写无关 - 右键该请求 →
Copy → Copy full URL,粘贴到新标签页直访——能打开说明原页面有 JS 拦截或 CSP 限制
href 值里藏着哪些肉眼看不见的坑
复制粘贴来的链接常带隐藏字符,W3C 不报错,但服务器拒收。
- 全选
href属性值 → 粘贴进记事本(不是 Word)→ 查开头/结尾空格、全角冒号:、中文引号“”、换行符 -
href="blog"和href="blog/"是两个资源:前者可能被重写为blog.html,后者才指向目录索引页 - 漏引号会直接导致解析失败,比如
在部分浏览器里只取到blog就截断了 - Linux 服务器大小写敏感:
About.html≠about.html;Windows 主机不敏感,但 CDN 或反向代理层可能区分
base 标签和构建配置不一致导致全局错位
会默默影响所有相对路径:不仅 ,连 <script src="app.js"></script> 和 CSS 里的 url(img.png) 都会被补上前缀。
- 检查 HTML 源码是否误加了
,尤其上线后才发现一堆资源 404 - 确认
href值结尾有没有多余斜杠:/subapp/和/subapp行为不同 - Vite 项目要同步检查
vite.config.ts中的base字段;CRA 项目看package.json的homepage - 没用子路径部署就别写
——现代构建工具默认不需要它
location.href 跳转时相对路径拼错
写 location.href = "user/profile",当前页面在 /admin/ 下,浏览器实际请求的是 /admin/user/profile,不是你想去的根路径。
- 改用绝对路径:
location.href = "/user/profile"(开头必须带/) - 更安全的动态写法:
new URL("user/profile", window.location).href,自动按上下文解析 - 别依赖
./前缀——某些构建工具或服务器会忽略它,行为不一致 - 如果跳转目标是锚点(如
#section2),确保目标id存在且合法(不能以数字开头、不能含空格)
最易被忽略的一点:404 错误本身是服务器明确返回的状态码,意味着请求已发出、路径已被解析、服务已响应。问题不在“有没有写链接”,而在于“浏览器以为它该去哪”和“服务器实际能提供什么”之间那条细微但致命的缝隙——Network 面板里的 Request URL 就是唯一能同时反映这两端的证据,盯住它,比反复检查 HTML 源码高效得多。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











