ServicePointManager.SecurityProtocol 属性用于指定新连接使用的 SSL/TLS 协议版本，默认值自 .NET Framework 4.7 起为 SecurityProtocolType.SystemDefault，使应用继承操作系统配置；此前版本无默认值，需显式设置如 Tls12 才能兼容现代服务端。
Visual Studio 中 .NET 接口调用报错，绝大多数情况不是代码写错了，而是运行时环境、协议协商或依赖加载没对上。直接看错误类型比盲目改代码更高效。
“请求被中止：未能创建 SSL/TLS 安全通道”
这是 .NET Framework 4.0/4.5 项目最典型的接口失败现象，本质是客户端默认不支持服务端要求的 TLS 版本。
-
ServicePointManager.SecurityProtocol在 .NET 4.0 默认只含Tls（即 TLS 1.0），不含Tls11或Tls12；而现代 API 普遍已禁用 TLS 1.0 - 必须在发起请求前强制启用：在
Main()、Application_Start()或第一个 HTTP 调用前加一行：ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12; - 如果项目锁死在 .NET 4.0 且无法升级，不能只写
Tls12——某些旧系统会因枚举值不存在而抛ArgumentException，得用数值硬编码：ServicePointManager.SecurityProtocol = (SecurityProtocolType)12288 | (SecurityProtocolType)3072; - 注意：该设置是进程级全局生效，一旦设错（比如设成
Tls单独一个），可能影响其他组件通信
Content-Type ‘application/x-www-form-urlencoded;charset=UTF-8’ is not supported
明明代码里写了 client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"))，但服务端却收到表单格式——说明请求体根本没走 JSON 序列化路径。
Visual Studio Professional 18.8.1
下载
Visual Studio 18.8.1 官方固定版本安装引导程序，当前条目使用微软发布历史中的 Professional Web Installer，适合旧项目兼容、环境回退、复现特定构建链和排查版本差异等场景。
- 常见误操作：
PostAsync(uri, new StringContent(json, Encoding.UTF8, "application/json"))写成了PostAsync(uri, new FormUrlEncodedContent(...))，后者会自动覆盖 Header 并发 x-www-form-urlencoded - 检查你传入
PostAsync的第二个参数类型：如果是StringContent或JsonContent（.NET 5+），才真正发 JSON；若用了FormUrlEncodedContent、MultipartContent或ObjectContent（WCF 风格），Header 就会被忽略或重写 - 用 Fiddler 或 Wireshark 抓包确认实际发出的请求体和 Content-Type，别信 IDE 里的变量预览
CS0006：未找到元数据文件 “xxx.dll”
编译阶段就卡住，不是运行时报错，说明引用链在构建时就断了。重点查 NuGet 还原和输出路径一致性。
- 先删掉项目目录下的
bin和obj文件夹，再右键解决方案 → “还原 NuGet 包”——很多时只是缓存错位，不是包真丢了 - 检查
.csproj里有没有混用PackageReference和packages.config，二者不可共存；若有老项目迁移痕迹，统一改为PackageReference格式 - 多目标框架（如
<TargetFrameworks>net472;net6.0</TargetFrameworks>）下，不同框架的依赖可能装在不同子目录，确保你当前选中的启动项目目标框架与引用的 DLL 编译目标一致 - 如果引用的是本地
.dll（非 NuGet），确认其属性 “复制到输出目录” 设为 “始终复制”，且该 DLL 本身不依赖缺失的运行时（比如它内部用了Newtonsoft.Json 13.0.0.0，但项目只装了 12.x）
“未能加载文件或程序集” 类型错误（如 Newtonsoft.Json、SAPNCO）
这类错误往往出现在首次部署或切换开发机后，核心是 GAC、运行时绑定重定向或 CPU 架构不匹配。
- 对于
Newtonsoft.Json版本冲突：检查app.config或web.config中是否有<bindingRedirect>，目标版本是否与实际安装的 NuGet 包一致；若无，手动添加并确保oldVersion覆盖全部可能范围（如0.0.0.0-13.0.3.0） - 对于
sapnco.dll类错误：右键项目 → 属性 → “生成” → 平台目标从Any CPU改为x86（SAP 官方库仅提供 32 位）；同时确认 IIS 应用池“启用 32 位应用程序”为 True - 所有“未能加载”类错误，打开 Windows 事件查看器 → Windows 日志 → 应用程序，筛选来源为
.NET Runtime，里面常有比 VS 输出窗口更详细的加载失败堆栈，包括具体缺哪个依赖、尝试从哪几个路径找过
真正难排查的从来不是错误信息本身，而是它发生的上下文：是本地能跑发布后崩？是调试模式正常但 IIS 托管失败？还是只在某台机器复现？先锁定「变化点」——哪怕只是换了个 NuGet 包版本、升级了 Docker Desktop、或同事改了某行 config，都比对着异常消息空猜强得多。
