404错误是服务器明确返回“资源未找到”，需定位请求路径与实际文件位置不匹配问题：检查src/href路径、大小写敏感性、web服务器配置（documentroot/root）、静态文件托管规则，并用network面板或curl验证响应状态码是否为404。
HTML 404 错误不是代码写错了，而是浏览器发了一个请求，服务器明确告诉你：“这个地址下啥也没有”。解决它不靠改 HTML 标签语法，而要定位那个“被请求却不存在”的资源路径。
检查 src、href 和实际文件位置是否匹配
这是最常踩的坑。浏览器按 URL 解析路径，不是按你本地文件夹结构猜路径。
-
img标签的src="images/logo.png"要求服务器上存在/images/logo.png这个可访问路径，而不是“当前 HTML 文件同级目录下有个 images 文件夹” -
a标签的href="about.html"会被解析为相对于当前 URL 的路径。如果用户在http://localhost/blog/post1/页面点这个链接，实际请求的是http://localhost/blog/about.html，不是根目录下的about.html - Linux 服务器对大小写敏感：
logo.png和Logo.png是两个文件；Windows 下可能不报错，一上线就 404 - 别依赖
file:///协议下的相对路径行为——那套规则和http://localhost完全不同
确认 Web 服务器是否真在服务你的文件
404 不等于“文件丢了”，也可能是“服务器根本没管这个文件”。
- 用
curl -I http://localhost/index.html或浏览器 Network 面板看响应头：必须有HTTP/1.1 404 Not Found（说明服务器收到了但找不到），而不是连接超时或Connection refused（说明服务没起来） - Apache 要检查
DocumentRoot是否指向你放 HTML 的目录；Nginx 要核对root或alias配置 - Django/Flask 等框架默认不托管静态文件：图片不能直接放模板同级目录，必须进
static/目录，并用{% static %}或url_for('static', filename='...')生成路径 - Jenkins/Jetty 等嵌入式服务器对
iframe src的相对路径解析很特殊——它按请求 URL 路径算，不是文件系统路径。此时应改用完整 URL，如src="http://localhost:8080/reports/detail.html"
验证自定义 404 页面是否真返回 404 状态码
很多人做了个好看的 404.html，但后端仍返回 200，这叫“软 404”，对 SEO 是灾难。
- 用
curl -I http://yoursite.com/this-page-does-not-exist检查响应头第一行，必须是HTTP/1.1 404 Not Found - Apache：
ErrorDocument 404 /404.html即可，它默认保持状态码；但若用RewriteRule重写，需加[R=404] - Nginx：
error_page 404 /404.html;后，务必加location = /404.html { internal; }，否则外部可直连该页并返回 200 - PHP 页面里必须开头调用
http_response_code(404)，再输出 HTML - GitHub Pages、Vercel 等静态托管平台不支持自定义状态码，它们的 404 页面本质是前端路由兜底，返回的仍是 200 —— 这是平台限制，不是你配错了
真正难的不是找到哪个路径错了，而是意识到：404 是一个 HTTP 协议层面的协商结果，它发生在浏览器和服务器之间，和你写的 HTML 是否合法几乎无关。盯住 Network 面板里那个红色的 404 请求，复制它的 Request URL，然后去服务器上逐级检查路径、权限、配置，才是正解。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
