页面返回时状态丢失的根本原因是浏览器默认仅保存URL和极简渲染快照（bfcache有限且不可控），DOM状态、滚动位置、表单输入、JS变量均不保存；iOS Safari尤其激进，常直接硬重载，pageshow事件中persisted为false即为明证。
页面返回时状态丢失的根本原因
不是浏览器“不保存”，而是它默认只保存 URL 和极简的渲染快照（bfcache 有限且不可控），DOM 状态、滚动位置、表单输入、JS 变量全都不在保存范围内。iOS Safari 尤其激进，多数情况下直接丢弃页面重新加载。pageshow 事件里的 persisted 属性为 false 就是明证——你看到的“刷新”，其实是浏览器放弃缓存后的硬重载。
用 sessionStorage 保存关键状态最简单可靠
适合表单字段、分页参数、选中 tab 等轻量级状态，无需额外库，兼容性好。
- 跳转前存：在离开页面前（比如点击链接或提交表单时）把数据序列化进
sessionStorage，例如sessionStorage.setItem('searchState', JSON.stringify({ keyword: 'foo', page: 2 })) - 返回后取：在目标页
DOMContentLoaded或 Vue/React 的mounted/useEffect中读取并恢复，注意判空：const state = JSON.parse(sessionStorage.getItem('searchState') || '{}') - 用完即删：恢复后立刻
sessionStorage.removeItem('searchState')，避免跨会话污染；若需多步返回保留，改用localStorage并加业务标识前缀 - 别存大对象：
sessionStorage限制约 5–10MB，但实际应控制在 KB 级，只存 ID、关键词、页码等标识，不要存整个列表数据
用 location.hash 同步查询参数与 URL
适用于搜索页 → 详情页 → 返回搜索页这类场景，用户能直接复制带条件的 URL 分享，且浏览器返回键天然支持。
- 提交搜索时，把参数拼成字符串塞进 hash：
location.replace('#?keyword=foo&page=2')，用replace避免历史栈堆积 - 页面加载时解析 hash：
const hash = location.hash.substring(1); const params = new URLSearchParams(hash)，再填表单、触发 AJAX - 注意：hash 变更不会触发页面刷新，但会触发
hashchange事件，可监听做动态更新 - 别用
location.hash = '...'直接赋值——它会 push 新记录；必须用replace或assign控制历史行为
history.pushState + popstate 是唯一真正可控的方案
如果你需要精确控制滚动位置、动画过渡、或多个嵌套状态（比如 tab + 搜索 + 排序），就必须接管 history。
立即学习“前端免费学习笔记（深入）”；
- 跳转前先更新 UI（渲染新内容、滚动到位置），再调用
history.pushState({ tab: 'detail', id: 123 }, '', '/item/123') - 监听
popstate：仅当用户点浏览器返回/前进按钮时触发，event.state就是你传进去的对象，据此恢复状态 -
history.state在页面首次加载时为null，不能依赖它初始化；首次加载逻辑要单独写 - state 对象必须可序列化：不能含函数、DOM 节点、Date 实例；超 640KB（Chrome）会静默失败
复杂点在于：这三套机制不是互斥的，而是常要组合用。比如用 pushState 管理路由和主状态，用 sessionStorage 存临时表单草稿，用 hash 做对外可分享的查询参数——真正难的不是写哪一行代码，而是想清楚每种状态该归谁管、何时存、何时清。
