Chrome Devtools Dedicated Node.js Inspector不会在断点处停止

Question

关于这个问题有几个较旧的帖子，但是2013年和2014年提出的问题的日期以及那里的答案对我的案例没有帮助。

我将debugger关键字放在我的文件中的多个位置，甚至在检查器UI中添加了手动断点。但是，执行文件并不会在任何断点处停止。我使用的是节点9.2.0和chrome 64.0.3282.167。

这是我的devtools如何出现的图片。

Answer 1

自从10.13到LTS并从8升级到10以来，这个问题一直困扰着我。

直到在堆栈溢出处看到此问题之前，我无法找到任何有关此问题的信息，这是促使我找到更多有关该问题并找出原因和解决方案的催化剂。

您可以在此处找到更多信息：https://github.com/nodejs/node/issues/23693

原因： 基本上是因为Node中的调试器协议发生了变化。

解决方案： 将Chrome升级到支持协议更改的71或更高版本。

更好的解决方案：：安装NIM：https://chrome.google.com/webstore/detail/nodejs-v8-inspector-manag/gnhhdgbaldcilmgcpfddgdbkhjohddkj，然后转到NIM设置，然后将所选的DevTools版本从chrome-devtools-frontend.appspot.com更改为一个版本。关于此选项的信息：​​https://june07.com/blog/nim-custom-devtools-url/）

Answer 2

我也遇到了这个问题：Chrome Devtools Inspector不会在断点处停止。

我有问题的软件版本：

• Chrome：版本70.0.3538.77（正式版本）（64位）
• 节点：v10.12.0

我发现的一种解决方法是将NodeJS降级到 8.12.0 版本（最新的8.x版本）。节点版本8.x适用于我。

$ node -v
v8.12.0

我还尝试了Node版本10.13.0、11.1.0，它们都不适合我。

仅供参考：How to change Node version

Answer 3

使用--inspect-brk标志

我最终在devtools protocol github page上打开了一个问题。

我立刻得到了回答。基本上，因为我使用--inspect标志来启动Node.js调试器，所以我的JavaScript在调试器进程连接到DevTools服务器之前正在执行。因此，断点信息将被传递得太晚，并且不会触发断点。

示例：node --inspect-brk myscript.js

他们目前正在努力改进此用例。这是实际答复：

  

我们正在努力改善工作流程，但现在--inspect-brk是   只有一种方式。使用--inspect-brk节点等待DevTools前端   连接。在连接DevTools发送所有断点信息   并在节点中启动JavaScript执行。使用--inspect节点启动   JavaScript执行，无需等待DevTools前端。立刻   DevTools连接后，我们向节点发送相同的断点信息   但由于某些JavaScript已经执行，因此为时已晚。

截至4/6/2018，Node.js文档对于这一细微之处并不十分清楚。我将在他们的回购提交PR以更新文档。顺便说一句，如果您不知道，即使没有V8集成，内置调试器也非常强大。在docs中探索调试实用程序的所有可能性。

Answer 4

我今天在与10.13.0一起工作时遇到了同样的问题。根据答案4的评论，我使用$ nodenv local <version>测试了不同的版本，结果如​​下：

10.13.0（不起作用）

10.12.0（不起作用）

10.11.0（有效）

10.10.0（有效）

假定较低版本有效。

如果您不熟悉nodenv，可以在这里https://github.com/nodenv/nodenv

Answer 5

我发现，如果我手动键入：

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated from a template.
//
//     Manual changes to this file may cause unexpected behavior in your application.
//     Manual changes to this file will be overwritten if the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

namespace KysoWebApi
{
    using System;
    using System.Collections.Generic;

    public partial class Computer_Win_Installed_Software
    {
        public int ComputerId { get; set; }
        public string SoftwareName { get; set; }
        public Nullable<double> SoftwareVersion { get; set; }
        public Nullable<bool> IsServerSoftware { get; set; }
        public Nullable<int> SoftwareVendorId { get; set; }
        public string SoftwareIs32or64bits { get; set; }
        public int ComputerWinInstalledSoftwareEntryId { get; set; }
        public string EntryTimestamp { get; set; }

        public virtual Computer Computer { get; set; }
    }
}

我希望断点出现在我的代码中，然后这实际上为我解决了这个问题。 例如

debugger;

我通过以下方式运行以上内容： 节点--inspect-brk = 0.0.0.0：5000 test_debugger.js [这里是0.0.0.0，因为它在远程服务器上。]

Answer 6

我遇到了类似的问题并找到了一个简单的方法。而不是使用chrome devtools，尝试使用node-inspector，它执行相同的操作 - https://github.com/node-inspector/node-inspector#quick-start

1. 打开node.js命令提示符
2. 安装node-inspector包npm install -g node-inspector
3. node-debug <your-entry-point>将<your-entry-point>替换为您的'main'文件，默认情况下通常是app.js（请记住导航到完整的文件位置，如果还没有，例如C：\ Users ..）
4. 等待打开node-inspector的新浏览器窗口

Answer 7

更深层次的原因似乎是调试器维护两个单独的数据库，在该数据库中存储断点。从 Sources 标签打开文件并在其中设置断点是浪费时间。也许node认为这些可疑或未经证实-无论如何。他们被忽略。这些断点存储在“某处”，而不是存储在活动的调试会话找到或尊重它们的位置。

您需要首先设法中断要调试的源文件的活动执行，并然后在运行上下文中设置断点。您会注意到，以前通过 Sources 选项卡设置的所有断点都已消失，可以设置新的断点。在运行时，节点仅“观察”那些新断点。

所以今天（2019年9月）的解决方法如下：

1. 使用debugger;语句对要调试的源文件进行胡椒粉
2. 使用inspect-brk启动项目，以强制调试器在执行第一行之前停止程序
3. 单击蓝色小箭头继续正常执行； debugger;语句现在应该会在您感兴趣的源文件中中断。
4. 一旦停止，您可以设置断点，这些断点实际上将被观察到并保存在“正确的数据库”中（由于缺乏更好的用语）。