spa的html结构需预留语义化挂载点，如作为中性主容器，避免嵌套全局布局或业务命名节点；路由优先选history.pushstate（需服务端fallback）或hashchange（免配置但不利seo）；动态内容加载推荐fetch片段或内联template，渲染应清空重写而非show/hide以防止状态残留。
纯 HTML 文件无法动态加载内容，必须靠 JavaScript 控制路由 + 获取资源 + 替换 DOM；所谓“HTML 结构”只是静态骨架，真正决定 SPA 行为的是 JS 如何组织和更新它。
如何设计一个可被 JS 动态替换的 HTML 主容器
SPA 的 HTML 不是“写死内容”，而是预留语义化、可预测的挂载点。关键不是写多少标签，而是哪些标签能被 JS 安全、稳定地复用。
-
<main id="app"></main>是最常用且推荐的主视图容器，id便于document.getElementById('app')快速定位，语义上也明确表示“这是用户当前看到的核心内容” - 避免把
<nav></nav>或<header></header>套在<main></main>内部——它们属于全局布局，应独立存在；否则每次路由切换都可能误删导航栏 - 不要用
<div class="page-home"> 这类带具体业务名的容器做根节点，而要用中性名如 <code>app或view，否则后续加新页面就得改 HTML - 初始 HTML 中可以留空
<main></main>，也可以预设一个 loading 状态（如<p>加载中...</p>），但不能放实际业务内容——那会和 JS 渲染逻辑冲突 - 用
history.pushState：URL 看起来干净（如/about），但需服务端配置 fallback（比如所有非 API 路径都返回 index.html），否则直接访问/about会 404 - 用
hashchange：URL 带#（如#about），浏览器原生支持，无需服务端配合，但搜索引擎基本不索引#后内容，也不符合现代路由直觉 - 若项目要 SSR 或 SEO，优先
history模式；若只是内部工具或原型，hashchange更省事、更少出错 - 无论哪种，都必须监听
popstate（history）或hashchange（hash）事件来响应浏览器前进/后退，否则用户点返回按钮就卡住 - 用
fetch('/about.html')：适合内容较多、更新频繁的场景；HTML 片段可独立缓存、压缩，但多一次 HTTP 请求，首次切换有延迟 - 用
<template id="about"><h1>关于我们</h1> <p>...</p></template>：所有模板随主 HTML 一次性加载，切换极快，无额外请求；但主包体积变大，模板修改需重新发布整个 HTML - 混合策略可行：首页用内联
template，二级页面（如用户详情）用fetch加载，通过import('./user.js')懒加载对应逻辑 - 注意：
fetch返回的 HTML 字符串不能直接赋给innerHTML如果含<script></script>标签——那些脚本不会执行；需手动解析并eval或createScript，风险高，建议避免 - show/hide 保留 DOM 节点和绑定事件，若组件内有定时器、
addEventListener或第三方库实例（如图表），不销毁就会累积，最终卡顿甚至崩溃 - 屏幕阅读器对
display: none内容通常忽略，但若旧视图未移除，又没正确设置aria-hidden，可能造成播报混乱 - 用
innerHTML = newContent或replaceChildren()是更可控的方式；现代框架（Vue/React）底层也是类似思路，只是封装得更安全 - 如果真要复用 DOM（比如表单编辑页返回列表页再回来），应主动解绑事件、清除定时器、重置表单控件值，而不是依赖 CSS 隐藏
history.pushState 和 hashchange 该选哪个做路由基础
二者都能避免刷新，但行为差异直接影响 URL 感知、SEO 和服务端配合方式。
动态加载内容时，fetch HTML 片段 vs 内联 template 标签
本质是权衡网络请求开销与首屏体积，没有绝对优劣，取决于应用规模和部署条件。
为什么每次渲染都要清空再写入，而不是 show/hide 切换
看似 show/hide 更轻量，但实际在 SPA 中容易引发状态残留、内存泄漏和可访问性问题。
最容易被忽略的一点：SPA 的 HTML 结构不是“写完就扔”，它要经受住几十次 DOM 替换、多次 history push/pop、不同设备尺寸下的无障碍播报考验。语义标签不是装饰，而是让 JS 操作有据可依的契约。
