historyapi通过pushstate/replacestate可改url且不刷新页面，与location.href本质区别在于无网络请求和js重执行；需服务端配合fallback，且state对象须可序列化。
HistoryAPI能改URL但不触发刷新
能，history.pushState() 和 history.replaceState() 都可以修改地址栏 URL，且页面完全不重新加载 —— 这是它和 window.location.href 最本质的区别。浏览器不会向服务器发请求，也不会执行 HTML 解析、JS 重执行、CSS 重计算等整套刷新流程。
常见误判场景：
- 改完 URL 后手动按 F5 或点击地址栏回车 → 触发真实刷新（此时服务端必须能响应这个新路径）
- 改完 URL 后没同步更新页面内容 → 看似“没变”，其实是逻辑没跟上，不是 API 失效
- 在非同源页面调用 → 报
SecurityError，因为 HistoryAPI 只允许操作同源 URL
HTML刷新必跳转？取决于怎么“刷”
“刷新”这个词容易混淆，实际分三种行为：
-
location.reload()或 F5 / Ctrl+R → 浏览器向当前 URL 发 GET 请求，服务端返回新 HTML，强制全量重载 -
location.href = '/new'或location.assign('/new')→ 导航到新地址，等价于点击链接，必然跳转并刷新 -
history.pushState({path: '/new'}, '', '/new')→ URL 变、DOM 不变、JS 不重跑、无网络请求
关键点：只有前两种会“跳转”，第三种只是 URL 历史记录变更，用户甚至可以点浏览器后退按钮回到上一个 state。
立即学习“前端免费学习笔记（深入）”；
服务端对 HistoryAPI 路由的配合要求
HistoryAPI 改的是前端 URL，但用户直接访问该 URL（比如分享链接、新开标签）时，浏览器会发起真实请求 —— 此时服务端必须能返回正确的 HTML 入口文件（通常是 index.html），否则 404。
典型配置示例：
## Nginx 配置（防止前端路由 404）
location / {
try_files $uri $uri/ /index.html;
}常见坑：
- 开发时用
file://协议打开 HTML →pushState会报错（跨源限制），必须走 HTTP(S) 服务 - Vue Router / React Router 开启
history模式但没配服务端 fallback → 直接访问子路由返回 404 - 改 URL 后没监听
popstate事件 → 用户点后退，URL 变了但页面内容没响应
replaceState 和 pushState 的行为差异
两者都改 URL，但影响浏览器历史栈的方式不同：
-
pushState()：新增一条历史记录，用户可点「后退」回到前一个状态 -
replaceState()：替换当前历史记录，不增加长度，适合修正当前 URL（如去掉 hash、补全 query）
注意：pushState() 第一个参数是 state 对象，会被存入历史栈，后续通过 event.state 在 popstate 中读取；而 replaceState() 同样支持传 state，但不会新增条目。
错误用法示例：
history.pushState(null, '', '/user?id=123'); // ❌ state 为 null，后续 popstate 拿不到数据
history.pushState({userId: 123}, '', '/user/123'); // ✅ 推荐：把关键参数存进 state真正容易被忽略的是：state 对象不能包含函数或 DOM 节点（序列化失败），且大小受浏览器限制（通常几十 KB），超限会静默失败。
