第一条error是编译失败的根因，解决它可消除多数连锁错误；需检查目标框架与sdk匹配性、清理bin/obj/.vs/nuget缓存，并通过loaderexceptions定位运行时装配问题。
直接看“错误列表”窗口最上面那条 Error，它大概率就是编译失败的根因——其他错误往往是它的连锁反应，先解决它，多数问题会自动消失。
点开错误列表，聚焦第一条 Error
Visual Studio 底部的“错误列表”不是装饰。点击它（没显示就按 Ctrl+\、E），把筛选器切到“错误”，别被警告或消息干扰。双击第一条 Error，编辑器会跳转到对应代码行，并高亮出错位置。常见现象包括：
-
CS0246：类型找不到 → 通常是 NuGet 包没还原，或命名空间拼错 -
CS0234：命名空间中不存在类型 → 目标框架不匹配，或引用缺失 -
NU1102或NU1301：NuGet 包找不到 → 源配置错误、路径失效或缓存污染
注意：不要从堆栈里猜，也不要凭经验改别的地方——90% 的情况，修复这条就能让后续几十条错误一起消失。
检查目标框架和 SDK 是否真实可用
右键项目 → “属性” → “应用程序”页，记下 目标框架（比如 net8.0）。然后打开终端执行：
dotnet --list-sdks
如果输出里没有这个版本，dotnet build 就根本跑不起来，所有 CS 错误都是假象。此时：
- 去 dotnet.microsoft.com/download 下载对应 SDK
- 别只装 Runtime；必须装 SDK（含编译器）
- 重装后重启 VS，否则
dotnet --list-sdks可能仍不刷新
特别注意：VS 2022 自带的 .NET SDK 是独立安装的，和系统级 SDK 不共享，不能只依赖 VS 安装器里的勾选项。
清理缓存比“重启 VS”更有效
很多报错（尤其是智能提示失效、类型突然找不到、LoaderExceptions）本质是缓存错乱。光重启 VS 不够，要手动清三处：
-
bin/和obj/目录：右键解决方案 → “清理解决方案”，再删残留 -
.vs/目录：关掉 VS，进项目根目录，删掉隐藏的.vs文件夹 - NuGet 缓存：菜单栏 → “工具” → “NuGet 包管理器” → “清除所有缓存”
这三步做完再“重新生成解决方案”（Ctrl+Alt+F7），比反复点“生成”靠谱得多。尤其当项目刚从 Git 拉下来、或跨 VS 版本打开时，.vs 里旧的 IntelliSense 索引极可能损坏。
调试时遇到 LoaderExceptions 别急着改代码
弹窗报“无法加载一个或多个请求的类型”，点“查看详细信息”，重点看 LoaderExceptions 属性里的具体异常。在调试器“即时窗口”里输：
?$exception.LoaderExceptions
你会看到真实失败原因，比如：
-
Could not load file or assembly 'Newtonsoft.Json, Version=13.0.3...' — 已加载的是 12.x→ 版本冲突 -
Could not load file or assembly 'xxx' — 拒绝访问→ 权限或路径含中文/空格 -
Could not resolve type 'YYY' in assembly 'ZZZ'→ 强名称不匹配或 GAC 干扰
这类错误几乎从不发生在你写的代码里，而是运行时装配阶段出的问题。修复方向永远是统一引用版本、检查 deps.json 内容、或用 fusionlogvw 查加载日志——而不是去改 using 或加 [assembly: InternalsVisibleTo]。
真正卡住人的，往往不是错误信息本身，而是把它当成孤立事件去修。编译失败从来不是单点故障，而是一条链路上某处断裂的信号。盯住第一条 Error，验证它依赖的环境是否真实存在，比在几十个红波浪线之间来回跳转高效得多。
