搭车，这可能比预期的时间更长...
注意：所有侦听器都委派给“ body”，所有触发的事件也都位于“ body”上。
预期的页面加载流量
- 创建ID为#selectorA的选择器
- 为#selectA触发（“ aChanged”）的#selectA值更改注册（listener1）
- 如果条件为X，请为aChanged注册侦听器，以重新加载父页面（listener2）
- 注册将CSS更改应用于#selectorA（listener3）的aChanged的侦听器
预期的变更流
- 用户更新#selectA值-> $ .trigger（“ aChanged”）
- listener1听到aChanged->如果出现状况，则重新加载整个页面
- listener2在页面上听到一个div的aChanged-> $ .load（）
- listener3听到aChanged->更新一些#selectA元素的css类（不是元素，只是它们的css）
我的意图是，如果on-change-flow步骤2重新加载整个页面，其他侦听器可以执行他们想要的任何操作-还是失败，我不在乎，因为无论如何都正在重新加载页面。我的假设是，如果页面正在重新加载，则其他侦听器不会影响当前正在加载/新加载的页面的div / CSS。
我的问题
有时候但并非总是如此，当在满足条件X（重新加载页面条件）的两个或多个选项之间切换#selectA时，侦听器停止侦听-否则不会触发aChanged事件。
登录到控制台时，我注意到侦听器即将失败时（在未听到任何声音之前进行注册），loadPage-registerAllListeners的顺序会更改，而不是控制台日志来自索引页，它们来自VMxyz标识符（chrome的开发工具“此脚本未与URL关联”标识符）。如果将要失败，则大多数“注册侦听器”控制台日志都位于chrome的“导航至https：// ...”日志之前-所有这些日志均来自VMxyz标识符。
我的问题
- 我有点了解chrome的开发工具VMxyz标识符，但是我可以使用帮助来理解为什么-有时-这些console.log（）语句来自实际页面，以及为什么有时来自VMxyz。
- 我无法确定为什么听众有时会停止工作。在我看来，即使页面确实重新加载了侦听器中的操作，页面仍然会创建新的侦听器。
- 如果有人对我如何进一步调试或完全修复（请）提出建议，我将不胜感激。