江苏工伤联网接口常见问题与排查分析

1. 现象与用户问题描述

1.1 主要现象

没有 DLL 时，初始化接口能返回“找不到JSSiInterface.dll文件”的 JSON，说明 HTTP 服务和 C# 层逻辑是通的，异常能被捕获并返回。
有 DLL 时，如果 DLL 位数不对，会报 BadImageFormatException，已排除该问题。
有 DLL 且位数正确时，初始化接口返回 200，但没有任何返回内容（即 HTTP body 为空），其他接口状态是 cancel。
用官方测试软件，在同一目录下 DLL 能正常调用，说明 DLL 本身没坏，路径也没问题。

1.2 用户典型问题

“初始化报200，但没有返回任何信息，其他接口状态都是cancel。”
“把工伤dll去了，初始化接口能返回找不到DLL的错误。”
“用官方测试软件，调用同目录下的DLL没问题。”
“之前怀疑是DLL位数不对，已排除。”
“现在应该是什么问题？”

2. 代码逻辑梳理

2.1 主要流程

HTTP POST 到 /api/entry/workinjury
EntryController.cs 解析请求，分发到 JiangSuWorkInjuryBusiness
JiangSuWorkInjuryBusiness.cs
- 检查 DLL 是否存在
- 调用 Si_INIT 或 Si_Busi
- 捕获异常，返回 JSON

2.2 异常处理与 debug 逻辑

所有关键点均有 try-catch，catch 里会构造 JSON 返回。
只要没有致命崩溃，理论上都应该有 JSON 返回（如找不到 DLL、参数错、调用失败等）。

3. 为什么会出现“200但无返回内容”？

3.1 可能原因

进程崩溃
- 只要 C# 进程在处理请求时崩溃（如 DLL 内部崩溃、访问非法内存等），IIS/Kestrel 会直接断开连接，前端收到 200 但无 body。
- 这种情况 catch 也捕获不到，因为进程直接挂掉了。
死循环或阻塞
- 如果代码卡死在某一步（如 DLL 调用卡死），前端会超时，显示 cancel。
未正确返回
- 理论上所有分支都返回了 JSON，除非进程崩溃，否则不会无返回。

3.2 结合现象分析

没有 DLL 时能返回 JSON，说明异常捕获和返回逻辑没问题。
有 DLL 时无返回，说明只要进入 DLL 调用，进程就崩溃了，catch 也捕获不到。

4. 和官方测试软件的区别

官方测试软件能正常调用，说明 DLL 本身没坏，路径也没错。
服务用同样的 DLL 却崩溃，说明调用方式、参数、或运行环境有差异。

5. 代码层面可能的逻辑问题排查

5.1 DllImport 声明

[DllImport("JSSiInterface.dll", EntryPoint = "Si_INIT", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.StdCall)]
需确认 EntryPoint、CharSet、CallingConvention 是否和官方测试软件一致。

5.2 参数传递

Si_INIT(StringBuilder pErrMsg)
- StringBuilder 分配的长度是否足够？（建议 4096+）
Si_Busi(string inputdata, StringBuilder outputdata)
- inputdata 格式是否和官方测试软件一致？

5.3 运行环境

服务为 Web API，官方测试软件可能为 WinForm/Console，有些 DLL 只支持 STA 线程或有 UI 线程依赖。
IIS Express/Kestrel 运行权限、当前目录、依赖库路径等可能和官方测试软件不同。

5.4 依赖 DLL 问题

JSSiInterface.dll 可能还依赖其他 DLL（如 VC++ 运行库、其他业务 DLL），缺少依赖时也会崩溃。
建议用 Dependency Walker 或 Dependencies 检查依赖。

6. 建议的排查步骤

确认 DllImport 声明和官方测试软件完全一致（包括参数类型、调用约定）。
用 try-catch 包裹所有 DLL 调用，并在 catch 里加日志，确认是否能捕获到异常。
用 Process Monitor 监控 Web API 进程，看是否有 DLL 加载失败、依赖缺失。
用 Dependency Walker 检查 DLL 依赖，确保所有依赖都在 bin\x86\Release 下。
尝试用 Console 程序调用你的 DLL 代码，排除 Web API 环境差异。
确认 IIS Express/Kestrel 的启动目录和权限，和官方测试软件保持一致。

7. 结论

C# 代码逻辑本身没有明显问题，异常捕获和返回都很完善。
只要进入 DLL 调用就无返回，99% 是 DLL 内部崩溃或依赖缺失，不是 C# 代码逻辑问题。
建议重点排查 DLL 依赖、调用参数、运行环境差异。

8. 附：常见问题与术语解释

8.1 DllImport 只是声明，不会自动加载 DLL

只有实际调用方法时，.NET 才会去加载 DLL。
只是声明，不会报错，也不会加载 DLL。

8.2 "加载" DLL 的含义

指 .NET 运行时在调用 DllImport 方法时，将 DLL 文件加载到进程内存空间，并解析导出函数。
如果 DLL 位数不匹配、依赖缺失、导出函数签名不对，都会导致加载失败或调用崩溃。

9. 建议收集的信息（便于进一步排查）

DllImport 声明和官方测试软件的声明对比
传递给 DLL 的参数示例
Web API 运行方式（IIS Express/Kestrel/自托管）
官方测试软件的类型（WinForm/Console）

如需进一步协助，请补充上述信息，便于更有针对性地定位和解决问题。