“试图加载格式不正确的程序”是因进程与DLL位数不匹配，需确认DLL位数（x86/x64）并严格设置项目Platform target为对应架构，AnyCPU无效；导出名不匹配需用dumpbin查实际符号并指定CallingConvention和EntryPoint；部署崩溃多因缺失VC++运行库，须匹配安装；AssemblyLoadContext无法卸载原生DLL，热插拔需子进程方案。
调用第三方 DLL 时提示“试图加载格式不正确的程序”
这是典型的架构（x86/x64/anycpu）不匹配错误，不是代码写错了，而是进程位数和 dll 位数对不上。loadlibrary 失败、pinvoke 调用直接抛 badimageformatexception，都指向这个根源。
- 先确认第三方 DLL 是 32 位还是 64 位：用
corflags（.NET DLL）或dumpbin /headers xxx.dll（原生 DLL），看machine字段是x86还是AMD64 - 再检查你的 C# 项目平台目标：
Project Properties → Build → Platform target，不能设成AnyCPU（默认会跑在 64 位进程里，加载不了 x86 DLL） - 如果 DLL 是 x86，你的项目必须设为
x86；如果是 x64，就设为x64；别指望 AnyCPU + “首选 32 位”能兜底——它只对托管代码有效，对原生 DLL 无效
DllImport 导入后运行时报“找不到指定的程序”或“入口点未找到”
这通常不是路径问题，而是符号导出不匹配。C++ 编译的 DLL 默认用 C++ 名字修饰（mangled name），而 DllImport 默认按 C 调用约定查找未修饰名。
- 用
Dependency Walker或dumpbin /exports xxx.dll看实际导出的函数名，注意有没有前缀下划线（如_MyFunc@8）或完全变形的符号 - 在
DllImport中显式指定调用约定：CallingConvention = CallingConvention.Cdecl（对应 C 风格导出）或StdCall（Windows API 常用） - 如果函数名被修饰了，加
EntryPoint = "实际导出名"，比如EntryPoint = "_CalculateValue@12"；更稳妥的做法是在 C++ 侧用extern "C" __declspec(dllexport)导出
程序在开发机跑得好好的，部署到客户机器就崩溃
除了架构问题，大概率缺运行时依赖。第三方 DLL 往往依赖特定版本的 VC++ 运行库（如 vcruntime140.dll、msvcp140.dll）或 Windows SDK 组件。
- 不要手动复制 DLL 到输出目录——用
depends.exe或Process Monitor抓取加载失败的模块名 - 检查目标机器是否安装对应版本的
Microsoft Visual C++ Redistributable（注意区分 2015–2022 各版本，x86/x64 必须严格匹配） - 若无法要求客户装运行库，可考虑静态链接（C++ 侧编译时加
/MT），但会增大 DLL 体积，且部分功能（如 CRT 的多线程支持）可能受限
用 AssemblyLoadContext 加载 DLL 后无法卸载，内存一直涨
AssemblyLoadContext 确实能隔离加载，但“卸载”只对纯托管程序集有效；一旦涉及 P/Invoke 调用原生 DLL，该 DLL 会被操作系统全局加载进进程地址空间，Unload() 完全不起作用。
- 不要幻想靠
AssemblyLoadContext实现原生 DLL 的热插拔——Windows 不支持卸载已映射的原生模块 - 若需动态切换不同版本的第三方 DLL，只能启动子进程（
Process.Start），由独立进程承载调用，主进程通过 IPC 通信 - 频繁加载/释放场景下，优先评估是否真需要动态加载；多数情况，启动时一次性加载并缓存委托（
delegate* unmanaged）更稳定
架构匹配是第一道门槛，而原生依赖和加载上下文的边界，才是真正容易被绕开、最后卡住半天的地方。
