onhashchange仅在用户操作或浏览器导航导致hash变化时触发，如点击锚点、地址栏编辑、前进/后退或history API中URL hash实际改变；直接赋值location.hash不触发。
onhashchange 监听的是 window.location.hash 的变化，但**只在浏览器主动触发的 hash 变更时才触发**——不是所有赋值操作都会触发它。
onhashchange 什么时候真正触发
它只响应用户或浏览器行为引发的 hash 改变，比如：
- 点击
<a href="#section2">链接 - 手动编辑地址栏中
#后的内容并回车 - 按浏览器前进/后退按钮（且历史记录中 hash 不同）
- 调用
history.pushState()或history.replaceState()且新 state 的 URL hash 实际发生了变化（注意：仅改变 hash 时，pushState不会触发onhashchange；必须是浏览器导航意义上的 hash 切换）
而以下写法不会触发 onhashchange：
window.location.hash = 'new'; // ✅ 修改成功，但事件不触发 location.href = '#new'; // ✅ 触发（等价于用户点击锚点）
onhashchange 事件对象里 oldURL 和 newURL 的坑
event.oldURL 和 event.newURL 是完整 URL 字符串，但它们不一定包含 hash 值——尤其在页面刚加载、首次进入带 hash 的 URL 时，oldURL 可能是空字符串或上一页 URL（取决于浏览器实现），newURL 也未必带 #。
更可靠的做法始终是读取 window.location.hash：
window.onhashchange = function(e) {
const currentHash = window.location.hash; // ✅ 稳定、实时、带 #
if (currentHash === '#login') { /* ... */ }
};
不要依赖 e.oldURL.split('#')[1] 这类解析逻辑，容易出错。
兼容性与降级方案必须自己补
onhashchange 在 IE8+、Firefox 3.6+、Chrome 5+ 中原生支持，但 IE7 及更早版本完全不支持，且部分旧安卓 WebView 也有问题。
如果需兼容老环境，得手动轮询检测：
let lastHash = window.location.hash;
setInterval(() => {
if (window.location.hash !== lastHash) {
lastHash = window.location.hash;
// 手动模拟事件逻辑
handleHashChange();
}
}, 50);
注意两点：
- 轮询间隔别设太长（>100ms 用户感知明显延迟），也别太短（影响性能）
- 不能直接调用
window.onhashchange()—— 它可能为null或未定义；应封装成独立函数再调用
和 history.pushState / replaceState 混用时的误区
很多人以为 pushState({},"","#profile") 会触发 onhashchange，但它不会。因为 pushState 是 history API，操作的是整个 URL（包括路径、search、hash），但它的设计原则是「不触发任何 hash 相关事件」。
如果你同时用了 hash 路由和 history API，要注意：
- 仅靠
onhashchange无法捕获pushState改变 hash 的行为 - 若需统一监听，应优先使用
popstate事件，并自行维护一个 hash 快照做 diff - 现代前端路由（如 Vue Router 的 hash 模式）内部就是混合了
onhashchange+ 定时 fallback +popstate补充监听
最易被忽略的一点：hash 变化本身不发送网络请求，但若你把 hash 当作服务端路由（比如 Nginx 未配置 fallback），刷新页面时会 404——这和 onhashchange 无关，而是服务端配置问题。
