这是一个更普遍的问题，但我想其他人也遇到过这个问题——例如，参见这个 SO 问题:Ember.js: how to analyze error in vendor.js
我正在开发一个更大的基于 Ember 的应用程序，如果出现错误，我有时会得到相当神秘的堆栈跟踪，类似于此示例:
TypeError: e.indexOf is not a function
at e.func (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:13:6039)
at e.get (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:11:29357)
at Object.o [as isPath] (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:13:5640)
at Object.u [as set] (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:13:10630)
at n.set (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:16:725)
at n.cancel (https://XXX/assets/YYY-707bc84342df7a5350ea91fcc2b9bf53.js:1:20788)
at o.join (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:7:6400)
at Function.u.join (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:13:12315)
at https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:9:30923
at Object.h [as flaggedInstrument] (https://XXX/assets/vendor-c3ea8aab9a11f79411cf3b32532ea544.js:12:18911)
由于所有内容都引用/assets/vendor-*.js 文件，因此要准确找出错误发生的位置非常费力。
目前，我试图根据访问的端点和我对软件的了解来推断错误发生的位置。然而，这是非常不可靠和非结构化的，因为考虑到我的代码库的大小，错误通常非常模糊。
例如这里，很明显调用 indexOf() 的对象(可能是数组)可能未定义或为 null，因此，对其调用 indexOf() 不起作用，因此出现错误。但是猜猜有多少数组在几百个大型源文件中使用了 indexOf() ;-)
是否有更好、更结构化的方法可用于在这种情况下进行调试？
最佳答案
您可以通过在 Chromium 调试器中放置“异常暂停”并检查具有失败行的库来查看使用的库 js 文件。之后，您可以将 ember-cli-build.js 中的库引用从 libraryx.js 更改为 libraryx.src.js 或特定库的等效项。
关于javascript - ember.js: 如何基于 assets/vendor-*.js 进行调试，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45675242/