如何定位Ember.js应用中hashchange事件的触发源？

当然可以通过断点调试和调用栈分析找到问题根源，下面是具体的实操方法：

1. 给hashchange处理器加断点 #

• 直接在你贴出的this._hashchangeHandler函数里（比如var path = _this.getURL();这一行）打个断点。Chrome或Firefox的开发者工具里，找到对应代码行点行号就行。
• 触发那个会导致重定向的特定条件，断点命中后看调用栈面板。虽然最底层是hashchange事件，但往上翻栈帧，大概率能找到触发哈希变化的代码——可能是直接改window.location.hash，或是调用了Ember的transitionTo/replaceWith，也可能是某个第三方插件的跳转逻辑。

2. 追踪哈希修改的直接触发者 #

如果调用栈里没看到明确的触发代码，试试这个技巧：

• 在开发者工具控制台里运行这段代码，给location.hash的设置逻辑加个日志追踪：

  const originalSetHash = Object.getOwnPropertyDescriptor(window.location, 'hash').set;
  Object.defineProperty(window.location, 'hash', {
    set: function(value) {
      console.trace('hash被修改为:', value);
      return originalSetHash.call(this, value);
    }
  });
  

  每次hash被修改时，控制台会打印完整的调用栈，直接定位到改哈希的代码位置。

3. 排查Ember路由相关跳转 #

作为Ember应用，重点检查路由相关操作：

• 给Ember的transitionTo和replaceWith方法打断点。可以找Ember源码里的定义，或者你应用里封装的路由跳转方法，断点命中后看调用栈是谁发起的跳转。
• 检查路由的beforeModel/afterModel钩子，有没有条件性的跳转逻辑，这些钩子经常会触发哈希变化。

4. 排查第三方插件/依赖 #

因为你是多仓库多插件整合的应用，插件也可能是元凶：

• 先暂时禁用部分插件，一个个试，看哪个插件禁用后问题消失，缩小排查范围。
• 对可疑插件的代码加断点，跟踪它有没有修改哈希的操作。

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