NuGet包版本冲突本质是多个依赖对同一程序集提出互斥版本要求，导致.NET扁平化解析失败；需用dotnet list package --include-transitive定位冲突源，配合bindingRedirect解决运行时加载失败，并注意Directory.Build.props不覆盖已有高版本引用。
NuGet包版本冲突不是“装不上”，而是“装上了却跑不起来”或“编译过了但运行时报 FileNotFoundException”——根本原因在于多个依赖对同一程序集（如 Newtonsoft.Json、System.Net.Http）提出了互斥的版本要求，而.NET的扁平化依赖解析机制无法自动协调。
怎么看清谁在拖后腿：用 dotnet list package --include-transitive 定位冲突源
别靠猜。VS界面里点来点去看不到间接依赖，命令行才是真相入口：
- 打开项目根目录的终端（不是包管理器控制台），执行：
dotnet list package --include-transitive - 重点找重复出现的包名，比如两行都含
Newtonsoft.Json，但版本分别是12.0.3和13.0.1 - 再加
--vulnerable可顺带揪出已知安全漏洞的旧版 - 若输出太长，用
| findstr "Newtonsoft"（Windows）或| grep Newtonsoft（macOS/Linux）过滤
注意：dotnet list 只对 SDK 风格项目（即使用 PackageReference 的 .NET Core/.NET 5+ 项目）有效；老式 packages.config 项目得靠 Get-Package -ProjectName xxx 在包管理器控制台查。
手动改 .csproj 时，<packagereference></packagereference> 的写法有坑
直接编辑项目文件看似透明，但几个细节错一点就白干：
- 不要只改
Version属性，还要确认Include名完全一致（大小写敏感），比如Newtonsoft.Json≠newtonsoft.json - 避免混用方式：一个项目里既有
<packagereference></packagereference>又有<reference></reference>指向本地 DLL，尤其像OpenCvSharp这类混合托管/本地的包，会触发路径优先级混乱 - 如果想锁死版本（防止浮动更新），去掉
*或^，写成Version="13.0.3"而非Version="13.0.*" - 改完必须执行
dotnet restore或在 VS 中右键解决方案 → “还原 NuGet 包”，否则project.assets.json不刷新，改动无效
运行时报 Could not load file or assembly 'xxx, Version=A.B.C.D' 怎么办
这是典型的运行时绑定失败，还原和编译都过了，但加载器找不到匹配的程序集——这时候光改 .csproj 没用，得动配置文件：
- WPF 项目检查根目录是否存在
App.config；没有就新建一个，确保生成操作为Content，复制到输出目录设为Copy always - 在
<configuration></configuration>内添加<runtime></runtime>节，例如强制所有Newtonsoft.Json请求都重定向到13.0.3：
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json"
publicKeyToken="30ad4fe6b2a6aeed"
culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-13.0.3.0"
newVersion="13.0.3.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
publicKeyToken 值必须准确，可从已安装的 Newtonsoft.Json.dll 属性 → “详细信息”页复制，或用 sn -T path\to\Newtonsoft.Json.dll 查。
Directory.Build.props 统一版本时最容易忽略的限制
用 Directory.Build.props 是团队级解法，但不是万能膏药：
-
<globalpackagereference></globalpackagereference>只影响新添加的引用，不会覆盖已有高版本的<packagereference></packagereference>—— 必须手动删掉子项目中已存在的同名引用，否则它俩共存，冲突照旧 - 统一版本后若编译失败（比如报
CS0234找不到类型），说明某个上游包内部用了该版本移除的 API，这时不能硬推统一，得查那个包的lib/netX.X/目录是否兼容你的目标框架 - 对
Microsoft.Extensions.*系列包慎用全局统一，它们的大版本升级（如 5.x → 6.x）常伴随行为变更，盲目降级可能导致 DI 容器初始化失败
真正麻烦的从来不是怎么统一版本，而是当两个关键依赖分别锁死了不相交的版本区间时，你得亲手拆开其中一个包，看它能不能在不改代码的前提下适配另一个版本——这时候，project.assets.json 里的依赖图就是唯一可信的地图。
