“ReSharper扩展什么时候能支持调试？”过去一年里，这是JetBrains社区被问得最多的问题。现在答案来了：2026.2版本中，调试功能的第一版正式上线。有意思的是，这次上线的意义远不止“又一个功能落地”——它打通的，是一整套被官方限制堵了很久的工作流。

先把话挑明：这次更新的对手盘其实不是某个竞品，而是微软的许可策略。官方C# Dev Kit和C#扩展只允许在“正版”Visual Studio Code上运行，Cursor、Google的Antigravity IDE、Devin Desktop、Kiro这类兼容编辑器一概被挡在门外。这就导致一个很拧巴的局面：你用着为AI辅助编程优化的编辑器写C#，但到了调试环节，还得再打开一个Rider或者VS，在两个工具之间来回切屏。2026.2里的ReSharper调试器，直接把这个来回砍掉了。

打开网易新闻 查看精彩图片

下面我把这次更新的关键点拆成五条，每一条都踩在之前的痛点上。

第一条，调试器本身不是从头造的轮子，而是搬来了JetBrains Rider的核心调试引擎。这个引擎已经在一线线上跑了很多年，稳定性、断点触发精度这些看家本事直接继承了过来。所以拿到手里你就会发现，它不是一个“能跑就行”的初级调试器，初始版本就带了条件断点、命中次数断点、依赖断点和日志点——这些在微软扩展里也不算标配，在兼容编辑器上之前更是想都别想。

第二条，断点管理做到了代码沟槽直接操作。行号左边点一下设置断点，右键菜单能设条件、改命中次数，和原生体验一致。对于习惯了Rider的开发者来说，几乎没有学习成本。更关键的是，这套断点系统完全遵循VS Code的调试适配协议，所以你用惯了的那套“Step Over / Step Into / Step Out”步进逻辑，快捷键都和VS Code原生的保持一致，不会出现两套肌肉记忆打架的情况。

第三条，变量和表达式检查不再是“盲调”。通过VS Code的调试视图，可以直接看到运行时的变量值、监视表达式和调用堆栈，信息密度拉满。之前不少人用第三方编辑器写C#时，要么靠控制台输出顶一顶，要么干脆全凭猜，现在终于能实时盯状态了。这一点对Blazor和XAML开发者尤其重要，因为UI框架里状态漂移常常只差一两个赋值，能即时看到变量值，调试效率是指数级的差距。

第四条，启动和附加双模式全部到位。你可以直接从编辑器启动一个.NET、.NET Framework或Mono的调试会话，也可以附加到已经在跑的进程上。注意官方也补了一句：传统.NET Framework的启动有时会失败（比如WPF项目），目前的应急方案是先自己跑起来再附加调试。这个坑主要是因为.NET Framework的启动流程和现代协议有些兼容性磕碰，不过团队已经承诺后续版本会修，算是打了个补丁预告。

第五条，也是被社区吐槽最久的一条：工具链终于不割裂了。ReSharper扩展原本就集成了代码巡检、解决方案浏览器、重构、导航和单元测试，现在加上调试，等于把Rider那套完整的C#开发能力搬进了VS Code以及兼容的编辑器里。对于Cursor这类专门为AI配对设计的编辑器来说，意义更大：你可以在一个界面里完成AI生成的代码的审查、重构、运行和调试，不用再切到Rider里做最后把关。那种“AI写代码，真人跑回IDE里打补丁”的割裂感，至少在小项目和中型项目里可以直接消除了。

说到底，这次更新不是什么黑科技的首发，而是一个迟到但正确的补全。它解决的不是技术有没有的问题，而是工具使用权被官方许可锁死之后，开发者该去哪里拿到完整工作流的问题。ReSharper这条路，现在算是给出了一个实在的答案。