SPA跳转需拦截a标签默认行为，用history.pushState()更新URL并渲染视图；hash模式简单但SEO差，history模式需服务端fallback配置，避免刷新404。
index.html 里不能直接用 a 标签做 SPA 跳转
点击 <a href="/user"></a> 默认会触发完整页面加载，不是你想要的“无刷新路由”。SPA 要求拦截这种默认行为，否则每次跳转都重新请求 index.html 并丢弃当前 JS 状态。
必须手动阻止默认动作，并用 history.pushState() 更新 URL + 渲染新内容。常见错误是只改了 URL 却没调用视图函数，结果地址栏变了但页面内容不动。
- 用事件委托绑定到
document，避免漏掉动态插入的链接 - 检查
event.target.href是否同源：可用new URL(href).origin === location.origin - 只对相对路径（如
/post/123）拦截；带协议的绝对 URL（如https://xxx.com/）必须放行 - 拦截后立即调用
history.pushState(null, '', href)，再执行对应页面渲染逻辑
hash 模式最简单，但 URL 不够干净
不用服务端配合，window.location.hash = '/user' 就能改地址栏，且不触发页面刷新。监听 hashchange 事件即可响应变化。
缺点也很明显：URL 带 #（如 example.com/#/user），SEO 友好性差，部分老系统或分享平台会截断 # 后内容。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 初始化时需手动触发一次处理逻辑，因为首次加载不会触发
hashchange - 不要在
hashchange回调里再设location.hash，否则可能造成死循环 - 路径匹配建议用
location.hash.slice(1)去掉#，再比对字符串或正则 - 如果用
router-link类封装，记得把href写成#user而非/user
history 模式更专业，但服务端必须兜底
history.pushState() 能实现真正的 clean URL（如 example.com/user），但有个硬性前提：用户直接访问 /user 时，服务器不能返回 404，而必须返回 index.html。
否则刷新页面就崩了——这是 history 模式被误用最多的地方。Nginx、Apache、Vercel 都要配 fallback，GitHub Pages 则只能靠 404.html 曲线救国。
- Nginx 示例：
location / { try_files $uri $uri/ /index.html; } - Vercel：
vercel.json中加{"rewrites": [{"source": "/(.*)", "destination": "/index.html"}]} - 本地开发用 vite 或 webpack-dev-server 通常自带 fallback，但 build 后部署到静态托管时务必检查
- 别在
popstate里调pushState，否则前进/后退会无限触发
跳转后浏览器「返回」键失效？可能是 replaceState 用错了
用 history.replaceState() 会覆盖当前历史记录项，导致用户点返回时跳过这个状态。多数场景该用 pushState()。
唯一适合 replaceState() 的情况是：你刚做完登录重定向（比如从 /login 跳到 /dashboard），不希望用户按返回又回到登录页。
-
window.location.replace()是全局替换，整个历史栈删掉当前页，比replaceState()更激进 -
window.location.href = '...'是最朴素的跳转，一定会刷新，和路由无关 - 调试时打开浏览器开发者工具的「Network」标签，看跳转是否发起新 HTML 请求——如果是，说明路由没生效
- 移动端 WebView 或某些嵌入式环境可能禁用
pushState，需降级到 hash 模式
