VS Code「无调试运行」仍触发C++断点暂停是设计还是bug？

该表现不属于程序缺陷，是当前VS Code官方C/C++扩展的设计特性，和经典版Visual Studio的行为差异，来自两者对“无调试运行”的底层实现逻辑完全不同。

• 经典版Visual Studio的“无调试运行”，完全脱离调试组件直接拉起目标可执行程序。源码中标记的断点本质是IDE调试端生成的规则，没有调试器附着在进程上时，这些规则不会对运行的程序产生任何影响，自然不会触发暂停。
• 当前VS Code搭配官方C/C++扩展的“无调试运行”，并不是直接裸运行可执行文件：底层依然会启动对应平台的轻量调试器（即你配置中使用的gdb）来拉起目标程序，只是默认隐藏了调试交互界面、关闭了额外的调试能力入口。这种实现下，你在编辑器中设置的所有断点，会被自动同步给这个隐藏的调试器进程，自然会在断点位置触发暂停。

• 你在tasks.json的编译参数中加入了-g，生成的可执行文件带有完整的调试符号表，满足调试器加载断点的基本要求。
• 你的launch配置本身是基于gdb的cppdbg类型，扩展的运行逻辑会复用这套调试通路，不会因为你选择了“无调试运行”就跳过断点同步的步骤。

• 想要实现和经典VS一致的真·无调试运行效果：不要点击扩展自带的“无调试运行”按钮，直接在VS Code的集成终端中执行./hellowhox.exe即可，这种启动方式没有任何调试器附着，所有断点都不会生效。
• 如果希望使用扩展自带的运行按钮且不触发断点：打开调试侧边栏的断点列表，将所有断点临时禁用或删除。由于断点同步是自动完成的，只要存在激活状态的断点，隐藏的调试器就会在对应位置暂停。

补充说明：该行为早在社区被反馈过，官方的设计逻辑是为了统一运行通路，减少不同运行模式下的环境差异，并没有把“断点同步”的逻辑从调试器启动流程中剥离，因此才会出现和经典开发工具行为不一致的表现，并非实现错误。

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