iframe是最直接的嵌入方案，但需注意跨域限制、SEO不友好、可访问性差及移动端问题；fetch+innerHTML适合静态片段但不执行脚本；现代SPA应使用前端路由；服务端include才是真正的HTML调用。
iframe 是最直接的方案，但得小心跨域和语义问题
HTML 里调用另一个页面，iframe 是唯一原生支持“嵌入完整页面”的方式。它不是“调用”而是“嵌入”，浏览器会为它单独加载一个上下文，包括自己的 DOM、JS 执行环境和样式作用域。
- 如果目标页面和当前页同源（协议+域名+端口一致），可以直接用
<iframe src="other.html"></iframe>，JS 也能通过iframe.contentWindow有限通信 - 跨域时，
iframe仍能加载并显示内容，但 JS 无法读取其 DOM 或触发事件——这是浏览器安全策略，不是 bug -
iframe对 SEO 不友好，搜索引擎通常不索引其中内容；屏幕阅读器支持也较弱，影响可访问性 - 移动端上，
iframe容易出现滚动冲突或缩放异常，建议加scrolling="no"和sandbox属性限制能力
fetch + innerHTML 是常见替代，但只适合静态片段
想把另一个 HTML 页面的某部分“拉进来”并拼到当前页，很多人用 fetch 请求 HTML 字符串，再用 innerHTML 插入。这看起来像“调用”，其实只是字符串搬运，不执行脚本、不加载资源（如图片、CSS）。
- 默认情况下，
fetch('other.html')返回的 HTML 中的<script></script>标签不会执行；手动创建script元素并 append 也不安全，可能触发 CSP 报错 - 相对路径资源（如
<img src="logo.png" alt="一个html如何调用另一个页面" >）会以当前页面为基准解析，不是other.html所在目录，容易 404 - 适合场景：后台管理页中动态加载表单模板、帮助文档片段等纯结构内容；不适合加载带交互逻辑的独立模块
- 别用
document.write()替代——它会清空整个页面，且已废弃
现代框架里的“页面调用”本质是路由切换，不是 HTML 嵌入
如果你实际想实现的是“点击后展示另一个页面的内容”，那真正该做的是前端路由（如 React Router 的 <route></route>、Vue Router 的 router-view），而不是在 HTML 里硬塞另一个 HTML 文件。
- 所谓“调用另一个页面”，在 SPA 场景下是 JS 控制视图切换，HTML 文件只有一份（
index.html），其他“页面”其实是组件或模板字符串 - 直接在 HTML 中写
<script type="module" src="app.js"></script>启动应用，比反复iframe或fetch更可控、更利于状态管理 - 服务端渲染（SSR）或静态站点生成（SSG）项目中，“调用另一个页面”由构建工具决定输出结构，运行时仍是单页行为
服务端 include（如 SSI、PHP、Jinja）才是真正的“HTML 调用”
如果必须在 HTML 构建阶段就把另一个文件内容合并进来，就得靠服务端处理。浏览器本身没有 include 指令，所有“前端 include”都是模拟。
立即学习“前端免费学习笔记（深入）”；
- Apache 开启 SSI 后可用
<!--#include file="header.html" -->，但需服务器配置支持，且仅限同目录或指定路径 - PHP 直接
<?php include 'nav.php'; ?>，但要求后缀是.php，纯.html文件不解析 - 构建工具（如 Webpack + html-webpack-plugin、Vite 的
@vitejs/plugin-html）可在打包时注入内容，适合预编译场景 - 注意：服务端 include 无法解决跨域，也不能动态传参；所有逻辑都在服务端完成，前端无感知
真正难的不是“怎么写一行代码让另一个页面出现”，而是想清楚——你到底要共享状态、复用逻辑、隔离样式，还是仅仅复用一段 HTML 结构？不同目标对应完全不同的技术路径，混用容易掉坑里。
