蓝盐泳池19831. 先聊聊为什么“启动项目”这个默认设置这么坑
做 .NET 开发的朋友，尤其是长期在大型解决方案里写代码的人，应该都遇到过这种尴尬：解决方案里有十几个项目，Web 层、Service 层、Repository 层、工具类库各占一堆位置。你刚改完一个类库的代码，想跑一下某个控制台项目看看输出，结果按 F5 启动的还是上次调试的那个 Web 项目。这时候你只能停下手里的事情，到解决方案资源管理器里找到目标项目，右键，点“设为启动项目”，再按 F5。一次两次还好，一天要切五六次的时候，真的会怀疑人生。
我最初也以为这是 Visual Studio 的正常操作，毕竟微软的产品设计逻辑就是“解决方案是入口，启动项目是出口”。但用久了之后我发现，这个“正常操作”背后其实藏了不少可以绕开的路径。本篇文章我想把自己用下来最顺手的几种方案整理出来，核心目标是解决一件事：在多项目开发中，不修改启动项目设置，也能精准运行指定代码。这年头手头的活儿越多，越要减少无用操作，哪怕每次省十秒钟，一天积累下来也能多做不少正事。
这篇内容适合所有用 Visual Studio 做多项目开发的人看，不管你是刚入门的实习生，还是带团队的技术负责人，只要被“启动项目”这个默认设置折磨过，我相信都能从里面找到一两条立刻能用的技巧。文中涉及的操作我都在 VS2019 和 VS2022 上实测过，其他版本基本兼容，个别菜单名称有差异但思路是通用的。
先解释一个很多人没搞清楚的底层概念：Visual Studio 的“启动项目”到底管的是什么？调试器在按下 F5 的那一刻，需要知道自己该加载哪个项目的输出程序集、启动哪个进程、附加哪个调试器。这个信息就是“启动项目”决定的。默认情况下，一个解决方案只能有一个启动项目（也可以用“多启动项目”模式，后面详细说）。而所谓的“不用设启动项目就运行指定代码”，本质上就是绕过这个“唯一定位”的过程，让 VS 或者命令行工具直接告诉你“我要跑这个”。
理解了这一点，后面所有操作都有了逻辑支撑。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心思路拆解：绕过启动项目定位，无非三条路
我自己归纳了一下，当前解决这个痛点的方式基本分成三类，每一类都对应不同的使用场景和操作习惯：
第一类：右键直达。利用 Visual Studio 项目节点自带的调试和运行菜单，不经过解决方案层面的启动项目判断。这种方式最直观，适合临时想起哪个项目就顺手跑一下的场景。
第二类：外部命令接管。让操作系统的命令行、脚本或者 VS 的外部工具来承担“启动指定程序”这个职责。这类方法适合有固定运行脚本、需要传参、需要特殊环境变量配置的项目，尤其适合 Web 项目、Worker Service、Windows 服务这类不是“普通控制台程序”的组件。
第三类：配置策略变更。通过调整 Visual Studio 的“启动项目”设置逻辑本身，让多个项目在不频繁手动切换的情况下都能被正确处理。比如“多启动项目”模式、解决方案配置文件（.suo 目录下的隐藏配置）等。严格说这类方法还是动了启动项目设置，但如果你的需求是“多个项目同时启动”，那它比来回切换顺手得多。
三条路各有利弊，我用一张表先把它们的关键差异列出来：
| 方案类型 | 代表操作 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 右键直达 | 右键项目 -> 调试 -> 启动新实例 | 操作最快，无需记忆命令 | 每次都要鼠标操作，多个项目切换时手累 | 临时验证单个项目 |
| 外部命令 | dotnet run、devenv /Run、批处理脚本 | 可传参、可链式处理、可自动化 | 需要额外配置和记忆命令 | 有固定起点脚本的项目 |
| 配置策略 | 多启动项目、自定义启动配置 | 一次性配置后长期受益 | 初始设置繁琐，需要理解配置逻辑 | 反复运行多个固定项目 |
就我个人的经验来说，日常开发 80% 的场景用右键菜单就够了，剩下的 20% 复杂场景需要外部命令或配置策略补充。下面我按照这三个方向，把完整的操作步骤和踩坑记录都写出来。
3. 实操方案一：右键项目直接运行，最省事的精准启动
3.1 两种右键启动方式，别用混了
第一种方式，在解决方案资源管理器里找到你要运行的项目，比如一个叫 ConsoleApp.Demo 的控制台项目，鼠标右键点项目节点（注意不是解决方案节点，也不是项目里的某个文件），菜单里会出现一个“调试”子菜单，里面包含“启动新实例”和“逐步执行新实例”两个选项。
- 启动新实例：直接运行该项目，等同于按 Ctrl+F5（开始执行不