JS中location.reload与location.href赋值的区别

图 0：location.reload 与 location.href 属性赋值工程参数对照

在 JavaScript 中，location.reload() 与 location.href = ... 都可以让浏览器重新载入页面，但两者的底层运行机制有着本质区别：location.reload() 是方法调用，专注于当前文档的重新获取，保留原始 HTTP 请求方式且不增加历史记录；而 location.href 赋值是属性设置，本质是标准的页面导航行为，始终使用 GET 请求，默认向历史记录栈推入新记录，并支持跳转到任意 URL。

一、核心机制：方法调用与属性赋值的语义差异

从 ECMAScript 和 W3C/WHATWG 规范来看，Location 对象既提供了用于导航和重载的方法，也提供了反映当前 URL 结构的可读写属性。理解这两者的第一步，是明确它们在执行引擎中的角色定位。

1. location.reload() 的方法特性

location.reload() 显式指示用户代理重新加载当前资源。它的目标地址由宿主环境严格固定为当前页面的 URL，开发者不能向其传递自定义目标地址。

// 重新加载当前页面
window.location.reload();

在早期规范和旧版浏览器实现中，location.reload() 曾支持布尔值参数（如 reload(true) 用于强制从服务器拉取，绕过缓存；reload(false) 允许使用缓存）。但根据现代 WHATWG HTML 现行标准，reload() 方法定义已不接收任何参数，传参已被弃用。现代浏览器会根据标准的 HTTP 缓存控制头（如 Cache-Control、ETag、If-Modified-Since）自动进行缓存协商。

2. location.href 赋值的属性导航特性

location.href 是一个属性存取器（Accessor Property）。当对 location.href 进行赋值时，JavaScript 引擎会将其解释为一次显式的新文档导航请求。

// 导航至新页面
window.location.href = '/dashboard/overview';

// 重新载入当前页面
window.location.href = window.location.href;

即使赋值的目标地址与当前地址完全一致（例如 location.href = location.href），浏览器仍然会按照标准的导航管线解析目标 URL、执行安全上下文检查，并将其视为一次全新的地址栏输入导航。

图 1：location.reload 与 location.href 属性赋值的内部处理流水线

二、浏览器历史记录（History Stack）的行为差异

浏览器的会话历史管理直接决定了用户的“后退”和“前进”按钮交互体验。location.reload() 与 location.href 在历史记录栈上的表现完全不同。

1. reload() 对历史记录的原地维护

当调用 location.reload() 时，浏览器将这次操作视为对当前会话历史条目（Session History Entry）内容的重新抓取。历史记录栈的深度（window.history.length）不会增加，当前记录的状态也不会派生出新节点。用户点击后退按钮，依旧会直接返回到进入当前页面之前的上一个历史节点。

2. href 赋值向历史栈推入新条目

当执行 location.href = url 时，除非目标 URL 的路径和查询参数与当前完全相同且属于锚点变化，否则浏览器一律在会话历史栈顶部压入一个新的条目，并将 history.length 数值增加 1。

这也意味着：如果使用 location.href = location.href 来刷新当前页面，会在历史记录中产生一个重复的页面条目。当用户在刷新完成后点击浏览器的“后退”按钮时，浏览器会“后退”到刷新前的同一个页面，呈现出“后退失灵、原地没动”的糟糕交互假象。

图 2：两类操作对浏览器会话历史栈深度与后退指针的演化影响

三、HTTP 请求方式与表单重复提交问题

在实际项目开发中，最常暴露两者差异的场景是在处理由表单提交（尤其是 HTTP POST）渲染出来的页面时。

1. POST 请求与 reload() 的重发弹窗

如果当前页面是通过传统 HTML <form method="POST"> 提交后服务器返回的 HTML 页面，调用 location.reload() 时，浏览器遵循 HTTP 规范关于非幂等操作的防护约束。浏览器会保留原始请求的 Method（即 POST）以及原有的请求体数据。

为了防止用户无意中进行二次扣款、二次下单或重复插入数据，浏览器会自动中断请求流程，向用户弹窗警示：“确认重新提交表单？此网页需要用到你之前输入的信息”。只有在用户点击“继续”后，才会再次发出 POST 请求。

2. location.href 强制洗净为 GET 请求

与 reload() 相反，无论当前文档是经过多复杂的 POST 提交后呈现的，对 location.href 进行赋值赋值操作（哪怕赋给当前相同的 URL）都会由浏览器发起标准的 HTTP GET 请求。

这一机制会瞬间清洗掉之前可能存在的 POST 状态与请求体参数，绝对不会触发浏览器的“确认重新提交表单”对话框。在早期后端渲染（SSR）架构中，如果没有严格实施 PRG（Post/Redirect/Get）设计模式，前端开发者常常借助 location.href = location.href 来绕过弹窗，达到清空提交上下文的效果。

图 3：不同业务诉求与请求场景下的刷新策略判定树

四、锚点（Hash）响应与 URL 灵活性

在处理单页应用（SPA）或带有页面内锚点跳转的页面时，两者展现出了完全不同的响应规则。

1. 锚点与 location.href

如果对 location.href 赋值的内容仅仅改变了 URL 的哈希（Hash）片段，例如：

// 仅修改哈希锚点
window.location.href = '#section-spec';
// 或者指定包含相同路径的锚点
window.location.href = window.location.pathname + '#section-spec';

浏览器不会重新加载页面，也不会重新下载任何 HTML、CSS 或 JS 文件。浏览器仅会将视图滚动到对应 id 的元素位置，并在 window 上触发 hashchange 事件。这一特性常被用于不刷新页面的书签定位或轻量级哈希路由。

2. 锚点与 location.reload()

无论当前 URL 是否带有 #hash，调用 location.reload() 都毫无例外地会完整重新载入整个页面。它完全无视哈希变化对页面的无刷新优化逻辑，确保内存中的 DOM 树和 JavaScript 运行时彻底重置。

五、工程特性总结与实战选型

在企业级前端开发中，选型应严格建立在场景语义与浏览器标准之上。下表对两者的关键属性进行了汇总：

图 4：现代 Web 架构下的高频工程场景落地选型矩阵

综上所述，当你的目的仅仅是重新获取当前页面的最新数据并重置运行时状态时，应当使用 location.reload()，它既能保护用户的会话历史链路不受污染，又能准确响应各种 URL 条件；而 当你需要将用户带入一个全新的业务页面、或者需要强制发起一次纯净的 GET 请求时，才应该使用 location.href 赋值。在需要避免历史记录膨胀的重定向场景中，还可以配合使用 location.replace()。