404错误本质是请求URL与服务器真实文件路径不匹配，主因包括路径写错、协议用错、服务器配置错；应通过开发者工具Network面板确认实际请求地址，再比对并修正HTML中的href/src路径、部署结构或服务器配置。
404 错误不是文件“丢了”，而是浏览器发出的请求地址和服务器上真实文件位置对不上——路径写错、协议用错、服务器配置错，三者占九成以上。
先看 Network 面板里浏览器到底请求了啥
打开开发者工具（F12）→ 切到 Network 标签 → 刷新页面 → 找那个标红的 404 请求（比如 style.css 或 img/logo.png）→ 点开它 → 看 Request URL 字段。这个 URL 就是浏览器“以为”的路径，也是你修复的唯一依据。
- 如果显示
http://localhost/css/style.css，但你的 CSS 其实放在assets/css/下，那就得改href为assets/css/style.css - 如果显示
file:///C:/project/index.html下请求了./img/logo.png，但浏览器直接拦掉（尤其 Chrome），说明你不能双击打开 HTML，得走本地服务器 - 如果显示
http://localhost:8080/static-files/report.html，而你本意是加载同目录下的report.html，那大概率是 Jenkins/Jetty 这类服务把相对路径自动映射到了/static-files/前缀下，得换绝对路径或调整部署结构
相对路径写法必须匹配 HTML 文件的 URL 位置
浏览器永远按当前 HTML 的 URL 来算 src 和 href，不是按你在编辑器里看到的文件夹层级。比如：
-
index.html访问地址是http://localhost/blog/post.html，那么href="css/style.css"实际请求的是http://localhost/blog/css/style.css（不是根目录下的/css/） - 想从任意位置都指向项目根目录的 CSS，得用
href="/css/style.css"（开头带/） - 想确保路径不随 URL 变动，最稳的是把所有资源统一放
static/目录下，并在 HTML 中显式写全路径，比如src="/static/img/logo.png"
别信双击打开的“能运行”，那是假象
用 file:// 协议双击打开 HTML，很多路径行为会失效或被浏览器拦截，尤其是 iframe、fetch、XMLHttpRequest，甚至部分 img 和 link。这不是 bug，是安全限制。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- Windows 上双击打开
overview.html，里面src="../report/index.html"很可能报 404，但在 Linux 或某些浏览器里却能行——这恰恰说明它不可靠 - 解决方法只有两个：
npx http-server启一个本地服务器，或用 VS Code 的 Live Server 插件，让页面走http://127.0.0.1:8080/协议 - Tomcat、Django、Nginx 等正式环境更是如此：它们根本不处理
file://，只响应 HTTP 请求，路径逻辑也完全不同
大小写、扩展名、隐藏后缀，一个都不能错
Windows 下你感觉 logo.PNG 和 logo.png 一样，但 Linux 服务器会严格区分；你右键重命名时多按了一个空格，系统可能悄悄加了 .txt 后缀。
- 检查文件真实扩展名：Windows 要在文件资源管理器“查看”→勾选“文件扩展名”；macOS 用
ls -la；Linux 直接ls - 确认大小写完全一致：
Img/logo.png≠img/logo.png，部署前最好统一小写命名 - Django 等框架中，图片必须放进
static/目录，并用{% static 'img/logo.png' %}渲染，写./img/logo.png是无效的——框架不会自动提供模板同级目录的文件
真正卡住人的，往往不是路径本身多难写，而是你没意识到：浏览器发出的请求地址、服务器收到的 URL、文件系统里的物理路径，这三者根本不在同一个坐标系里。每次改完路径，务必回到 Network 面板，看那一行红色的 Request URL —— 它才是唯一可信的事实。
