HTML页面跳转报404，90%是路径与服务器请求上下文不匹配：相对路径（如./servlet/login）按当前URL解析而非文件系统，本地file://可运行，部署到Tomcat/Nginx即404；应优先用绝对路径、检查Network中实际请求URL、确认后端路由注册、iframe改用完整URL、核对部署结构及欢迎页配置。
直接说结论：HTML页面跳转报404，90%不是代码写错了，而是路径没对上服务器的请求上下文——href或src值看起来没错，但浏览器发出去的URL和服务器实际能匹配的资源路径不一致。
检查跳转链接是否用了相对路径
相对路径（比如./servlet/login、../api/data.json）在HTML中极易出错，因为它的解析基准是当前页面的**完整请求URL路径**，不是文件系统位置。本地双击打开file://能跑，一丢到Tomcat/Nginx就404，就是这个原因。
- 用浏览器开发者工具（Network标签页）看实际发出的请求URL，确认它是不是你预期的路径
- 把
./、../全换成以/开头的绝对路径（如/app/login），前提是你的应用部署在根上下文（http://localhost:8080/）；否则要带上上下文路径（如/myproject/login） - 如果项目部署在子路径（如
http://example.com/myapp/），建议用<base href="/myapp/">统一基准，再写相对路径
确认Servlet或后端路由是否注册成功
前端跳转地址写对了，后端没接住，照样404。尤其是用web.xml配置的老项目，或者Spring Boot里没加@RestController注解的类。
- 访问
http://localhost:8080/your-app-context/some-path，看是否返回404——如果连这个都404，说明后端根本没暴露该路径 - 检查
web.xml中的<url-pattern></url-pattern>是否和跳转地址完全匹配（注意尾部斜杠：/login≠/login/） - Spring Boot项目确认类上有
@RequestMapping("/api")且方法上有@GetMapping("/data")，路径拼起来才是/api/data - Tomcat启动日志里搜
mapped或servlet，确认对应路径确实被注册了
iframe src 404必须用完整URL
<iframe src="report.html"></iframe>这种写法，在Jenkins、Nginx静态服务、甚至某些CDN下极大概率404——因为iframe的src由浏览器按父页面URL解析，而服务器对静态资源的路由规则往往不支持../回退逻辑。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 一律改用完整协议+域名+路径：
src="https://example.com/static/report.html"或src="/static/report.html" - 避免依赖
document.baseURI或JS动态拼接，iframe加载发生在HTML解析阶段，JS还没执行 - 如果资源在同域但不同上下文（如Jenkins插件页面嵌套自己生成的HTML），必须显式带上上下文路径：
src="/jenkins/plugin/myplugin/report.html"
部署结构和欢迎文件容易被忽略
Tomcat默认只把index.html、index.jsp当欢迎页，如果你访问http://localhost:8080/myapp/想自动显示home.html，不配就404。
- 检查
WEB-INF/web.xml里是否有<welcome-file-list></welcome-file-list>，并包含你要的文件名 - 确保HTML文件真在
webapps/myapp/目录下，而不是webapps/myapp/WEB-INF/（这个目录下任何文件都不对外提供服务） - IDE（如IntelliJ/Eclipse）部署时可能过滤掉
.html扩展名，手动确认war包或输出目录里文件是否存在 - Linux服务器注意大小写：
Home.html≠home.html，Windows开发机上没问题，一上生产就404
最麻烦的情况是路径本身没错，但中间有反向代理（Nginx→Tomcat）、安全网关或CDN做了重写，导致请求在到达应用前就被截断或改写。这时候得查各层access log，逐段确认URL走到哪一步开始变样——别只盯着HTML代码改。
