使用window.history.go实现浏览器回退时为何加载全部中间页面？

首先明确：history.go(-n)并非在所有场景下都会直接跳转到目标页面，实际行为取决于浏览器实现、页面缓存状态以及历史栈的条目特性，你的场景里出现依次加载的情况主要有两个原因：

• 浏览器历史栈的处理逻辑：虽然从API设计意图上，history.go是直接跳转指定步数的历史记录，但部分浏览器在执行时，若中间的历史页面没有被缓存（或者缓存失效），会需要重新请求并加载这些页面来完成历史上下文的切换；尤其是当这些历史条目指向同一个URL（比如你的购物车页面多次刷新产生的条目）时，浏览器可能会逐个处理这些条目，导致视觉上出现依次加载的情况。

• 你的代码导致历史栈冗余：每次点击「更新」/「删除」按钮触发页面刷新时，都会在历史栈中新增一个购物车页面的条目，同时你通过myback变量累计需要回退的步数。当调用history.go(myback)时，浏览器需要跳过这些连续的购物车页面条目，但因为这些条目都是同个页面的不同加载状态，浏览器无法直接“跳过”，只能逐个回退处理，所以会依次加载中间的页面。

更优的替代方案（解决问题同时替换弃用API） #

既然performance.navigation.type已被弃用，且当前方案存在页面跳转的问题，建议用history.replaceState来优化：

每次点击「更新」或「删除」按钮时，先调用history.replaceState替换当前的历史记录，这样页面刷新后不会在历史栈中新增条目，而是覆盖当前的购物车页面条目。这样用户点击回退按钮时，会直接回到进入购物车前的页面，无需计算回退步数。

示例代码：

$(".myordersubmitbutton").click(function() {
    // 替换当前历史记录，避免新增条目
    history.replaceState(null, document.title, window.location.href);
});

这样处理后，历史栈中不会积累多个购物车页面的条目，回退操作会直接跳转到目标页面，也避开了performance.navigation.type的弃用问题。

内容的提问来源于stack exchange，提问作者Richard