pushState没反应是因为它只修改URL和历史记录，不触发刷新或加载新内容，需手动更新DOM并监听popstate事件；参数需合法，url须同源；replaceState替换当前项，pushState新增历史条目；服务端必须配置fallback路由，否则刷新会404。
pushState 为什么没反应？
直接调用 history.pushState() 不会触发页面刷新，也不会自动加载新内容——它只改 URL 和历史记录，后续渲染得自己写。很多人以为调用完就“跳转了”，结果页面静止不动，控制台也没报错。
- 必须配合路由监听（
popstate事件）或手动更新 DOM/组件 -
pushState()第一个参数（state）不能是 undefined 或函数，否则某些浏览器（如旧版 Safari）会静默失败 - 第二个参数（
title）目前所有主流浏览器都忽略，传空字符串''最安全 - 第三个参数（
url）必须同源，跨域会直接抛SecurityError
popstate 事件什么时候触发？
popstate 只在用户点击浏览器「后退」「前进」按钮，或调用 history.back()、history.forward() 时触发，不会 在 pushState() 或 replaceState() 调用时触发。
- 页面首次加载时，即使 URL 已带路径，
popstate也不会自动触发——得手动检查location.pathname并初始化视图 - 事件回调里的
event.state就是之前pushState()传入的 state 对象，注意它会被序列化/反序列化，函数和原型链丢失 - 别在
popstate里直接修改 history（比如又调pushState），容易陷入循环
replaceState 和 pushState 到底该选哪个？
核心区别就一条：是否新增历史条目。replaceState() 替换当前项，pushState() 往栈顶加一项。误用会导致用户点一次「后退」跳过本该停留的页面，或者点不完返回原始页。
- 表单提交后跳转成功页（如 /success），用
replaceState()—— 避免用户刷新后重复提交 - 从列表页点进详情页（/list → /item/123），用
pushState()—— 用户应能后退回列表 - URL 参数变更（如分页、筛选），优先
replaceState()，除非你明确希望每种筛选组合都可后退 - 两者参数结构完全一致，但
replaceState()不会触发popstate
服务端不配 fallback 会怎样？
前端用 History API 跳到 /dashboard/settings，用户一刷新，浏览器直接向服务器要这个路径。如果服务端没配置兜底（比如所有未知路径都返回 index.html），就会 404。
- 开发时用 Vite、Webpack Dev Server 可配
historyApiFallback: true - Nginx 需加
try_files $uri $uri/ /index.html; - Cloudflare Pages、Vercel、Netlify 默认支持，但自建 Node 服务（如 Express）必须显式处理
app.get('*', ...) - 这个不是前端能绕开的问题，部署前漏掉，线上必现白屏
实际用起来最麻烦的从来不是 API 本身，而是 state 的生命周期管理、路由与视图状态的同步、以及服务端那行小小的 fallback 配置——少一个，整个无刷新体验就断在用户手上了。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
