vscode的c#支持需手动触发初始化：打开.cs文件后，先执行ctrl+shift+p→dotnet restore，再developer: reload window强制重载，否则语言服务器不启动、launch.json不生成、调试器无法识别项目结构。
Ctrl+Shift+P 用不对，C#插件功能就卡在半路
VSCode 的 C# 支持不是开箱即用的，C# Dev Kit 和 Microsoft C# 扩展必须通过命令面板触发初始化。很多开发者装完就写代码，结果 F12 跳不到定义、Ctrl+. 不弹重构菜单——根本原因是扩展没真正加载。
正确做法是：打开任意 .cs 文件后，先按 Ctrl+Shift+P，输入 dotnet restore 并执行；再输入 Developer: Reload Window 强制重载。这一步能强制触发语言服务器启动，否则 launch.json 可能不自动生成，调试器也识别不了项目结构。
- 不要等右下角弹出“正在分析项目”，手动触发更可靠
- 如果
Output面板里C#通道长时间卡在 “Starting OmniSharp” 或报Could not resolve SDK，说明.NET SDK路径没被识别，需检查dotnet --version是否可用 -
Ctrl+Shift+P输入C#:可看到所有 C# 专属命令，比如C#: Show Project Outline，这是判断插件是否就绪的最快方式
Alt+F12 查看定义时，光标位置决定能不能看到真实签名
Alt+F12 是 C# 开发中查方法签名最常用的快捷键，但它对光标位置极其敏感。光标落在方法名上、括号内、参数名上，看到的内容完全不同——不是 bug，是设计如此。
例如在 Console.WriteLine("hello"); 中：
- 光标停在
WriteLine上 → 显示完整重载列表（含所有参数类型） - 光标停在
"hello"内 → 显示string类型的ToString()签名 - 光标停在左括号
(后 → 弹出参数提示浮层，显示当前重载的参数占位符
很多人误以为 Alt+F12 失效，其实是光标没放对位置。配合 Ctrl+Shift+O 先跳到符号定义处，再用 Alt+F12 查细节，效率更高。
Ctrl+D 在 C# 里选词逻辑和 JS 不一样
Ctrl+D 在 C# 文件中默认只匹配“完整单词”，不会跨标识符边界。比如变量名 userEmail，光标放在 email 上按 Ctrl+D，不会选中 userEmail，只会找独立出现的 email 字符串。
这是因为 C# 扩展启用了 editor.wordSeparators 的严格分隔规则（默认包含 .、、<code>>、: 等）。想让它像 JS 那样支持驼峰匹配，得改配置：
"editor.wordSeparators": "`~!@#$%^&*()=+[{]}\|;':",./?",
但要注意：改完后 Ctrl+D 会把 MyClass.MethodName 拆成 MyClass 和 MethodName 分别匹配，可能误选。更稳妥的做法是用 Ctrl+Shift+L 全选后再手动删掉不需要的匹配项。
调试时 F5 启动失败，大概率是 launch.json 缺了 net8.0 对应的 runtime
C# 项目若目标框架是 net8.0 或更高，而 .vscode/launch.json 里 configurations 的 runtimeVersion 还写着 6.0 或空着，F5 就会报 Could not find .NET SDK 或直接卡在 “Preparing debugger…”。
解决方法不是重装 SDK，而是检查 launch.json 中的 console 和 runtimeVersion 字段：
- 确保
"console": "integratedTerminal"（避免 Windows 上弹黑窗） - 显式指定
"runtimeVersion": "8.0"（与.csproj中<targetframework>net8.0</targetframework>一致） - 如果项目是多目标（如
net6.0;net8.0），runtimeVersion必须对应当前活动的 SDK 版本，可通过终端运行dotnet --list-sdks确认
这个配置项容易被忽略，因为 VSCode 有时会自动生成一个“看起来能用”的 launch.json，但 runtime 版本没同步更新，导致调试链路断在第一步。
