用Visual Studio 2017快速回答这个老问题。

如果可能的话，只需剪切并粘贴带有断点的代码。断点随着切割而消失。

Start your debug session with a minimal number of files open, as you debug the unwanted breakpoints will show up and the containing files will open in new tabs. Terminate the debug session and open the breakpoints window (from the debug toolbar, for some reason it is not in the view menu). For each file, enter the name of the file in the search area of the breakpoints window and press enter to filter out the breakpoints by file. You can then click on each breakpoint in the window to see where they are located in the code and delete them if you want. A bit tedious but that the best way I found to get rid of those unwanted ghost breakpoints... Bookmarks and breakpoints management.. Those functions were probably last enhanced sometime during the last century...

用Visual Studio 2017快速回答这个老问题。

如果可能的话，只需剪切并粘贴带有断点的代码。断点随着切割而消失。

我认为这是一个设计缺陷，它非常令人沮丧，我们不得不长期忍受。我们经常碰到它，这已经成为常态。到目前为止给出的解决方案都是可行的。

一个更好的解决方案是聚在一起投票改变Visual Studio用户声音。这似乎已经被记录了几次，所以我们应该选择一个投票。

https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/31123351-delete-disable-break-point-while-debugging-should

去调试>窗口>断点，找到断点，并从窗格中删除它们。

正如这里的回答

这里有一些答案，但在我看来，在调试期间使用建议的操作会分散注意力(我不想失去我的注意力)。

我在断点期间使用粘断点的流程如下:

在调试期间，禁用断点，而不是删除它。

禁用断点的可能方法:

鼠标悬停，点击两个循环图标; 或者使用上下文菜单; 或键盘快捷键CTRL+F9(不是Shift+CTRL+F9，因为它清除所有断点)。

稍后，在开发过程中，当我看到一个禁用的断点时，我会删除它。

PS.偶尔删除所有断点也是一个很好的实践。