BadImageFormatException本质是.NET进程位数与Oracle本机DLL架构不匹配，需严格对齐项目平台目标（x86/x64/AnyCPU）、Instant Client位数（win32/x64）及IIS应用程序池的“启用32位应用程序”设置，并注意PATH加载顺序和路径合法性。
BadImageFormatException 本质是进程位数与 DLL 架构不匹配
这个异常不是 oracle 配置错了，也不是连接字符串写错了，而是 windows clr 在加载 oci.dll、oraociei11.dll 等本机库时直接拒绝——因为你的 .net 进程是 64 位的，而它试图加载的是 32 位 instant client 的 dll。反过来也一样：x86 进程加载 x64 dll 同样失败。
关键判断点：BadImageFormatException: 试图加载格式不正确的程序 出现时，第一反应不是查 TNS 或权限，而是立刻确认两件事：
- 你的项目“平台目标（Platform Target）”设的是
x86、x64还是AnyCPU？ - 你用的 Oracle Instant Client 是哪个压缩包？文件名里带
win32就是 32 位，带winx64或x64才是 64 位 - 如果你在 IIS 上跑，还要看对应应用程序池的“启用 32 位应用程序”是否为
True
Visual Studio 项目平台目标必须与 Instant Client 严格对齐
哪怕只差一位，运行时就崩。常见错误组合和修正方式如下：
- 用了
instantclient-basic-win32-11.2.0.1.0.zip→ 项目属性 → “平台目标”必须设为x86，不能选AnyCPU（即使勾了“首选 32 位”，某些旧版 VS 或 IIS Express 下仍可能以 64 位启动） - 用了
instantclient-basic-windows.x64-19.22.0.0.0dbru.zip→ 平台目标必须是x64或AnyCPU（且取消勾选“首选 32 位”） - 混合部署场景（如开发机装了 64 位完整 Oracle Client，但发布时只放 Instant Client）→ 删掉 bin 目录下所有
Oracle.DataAccess.dll或OdpNet.dll，改用 NuGet 包Oracle.ManagedDataAccess，它完全托管，不依赖本机 DLL
IIS 应用程序池的 32 位开关常被忽略
本地调试通过，一上 IIS 就报 BadImageFormatException，大概率是这里卡住。IIS 不会自动适配你本地的平台设置。
操作路径：IIS 管理器 → 应用程序池 → 右键对应池 → “高级设置” → 找到 启用 32 位应用程序：
- 若你用的是 32 位 Instant Client → 必须设为
True - 若你用的是 64 位 Instant Client → 必须设为
False - 该设置修改后需手动“回收”应用程序池才生效，重启网站不够
PATH 环境变量和 DLL 加载顺序是隐形雷区
即使平台目标和 IIS 设置都对了，仍可能加载错 DLL——因为 Windows 按 PATH 顺序搜索 oci.dll，而你机器上可能同时存在多个 Oracle 安装（比如旧版 Oracle 10g Client + 新版 Instant Client），PATH 里靠前的路径指向了位数不匹配的版本。
排查建议：
- 在应用启动前，用
Process Explorer（Sysinternals 工具）查看你的进程实际加载了哪个路径下的oci.dll - 临时清空系统 PATH 中所有 Oracle 相关路径，只保留你当前要用的 Instant Client 解压目录，并把它加到 PATH 最前面
- 避免把 Instant Client 放在含空格或括号的路径里，比如
C:\Program Files (x86)\oracle\instantclient_11_2—— 某些 .NET 版本会因解析失败静默跳过该路径
最易被忽略的一点：Oracle.ManagedDataAccess 虽然能绕过所有位数问题，但它不支持某些高级特性（如 Wallet、外部过程调用、部分 LOB 操作）。如果业务强依赖这些，你就必须老老实实对齐位数，而不是寄希望于“换一个包就全解决”。
