这些年做机器视觉上位机，被问得最多的一个问题就是：C#里到底怎么把训练好的YOLO模型跑起来？很多人卡在Python那边训练好模型，一到C#就不知道怎么加载、怎么解析，网上的资料又多半是OpenCV DNN或者TensorFlow的老路子，换到ONNX Runtime就抓瞎了。
这篇东西我从实际工程出发，把C# + ONNX Runtime加载YOLO的完整链路捋一遍，重点放在模型加载和信息解析这两个最容易被忽略的环节。适合C#上位机开发、自动化设备集成、工业视觉检测这块的朋友参考，也适合刚入门YOLO部署、想搞清楚模型文件内部到底长什么样的人。我会用YOLOv8作为主要示例，因为现在它用得最多，导出ONNX也最省心。
不扯虚的，直接进入正题。
1. 项目整体设计与思路拆解
1.1 为什么是ONNX Runtime而不是别的方案
先回答一个最根本的问题：为什么要在C#项目里用ONNX Runtime来跑YOLO，而不是继续用Python，或者用OpenCV DNN？
先说Python。训练阶段用Python没问题，PyTorch训练完直接export成ONNX，非常流畅。但一旦到了产品落地，你就得把模型嵌入到上位机软件、工控程序里，这时候纯Python方案往往意味着要带上整个Python运行环境、一堆依赖库，部署到客户现场机器上很容易出各种幺蛾子。工业现场讲究的是稳定、可控、易部署，C#写上位机正好是这个领域的标配。
再说OpenCV DNN。它确实能加载ONNX模型，但问题不少：对YOLO的某些算子兼容性一般，比如一些自定义的NMS层或者较新的激活函数，OpenCV DNN版本跟不上就会直接罢工。另外OpenCV DNN在GPU推理上支持得比较挑，和TensorRT、ONNX Runtime这些专门做推理的引擎比，性能还是有差距。
ONNX Runtime的优势在于它是微软和社区一起推的跨平台推理引擎，对ONNX标准模型的支持最完整，CPU/GPU都能跑，而且C#这边有官方维护的NuGet包，API设计也还算顺手。简单说，它就是为“生产环境部署”这个场景准备的。
1.2 整体流程的四个阶段
整个YOLO模型从文件到最终拿到检测结果，拆开看其实就是四步：
- 模型加载：把训练好的YOLO模型（PyTorch格式等）导出为ONNX格式，然后在C#中用InferenceSession加载这个ONNX文件。
- 元信息解析：通过ONNX Runtime提供的API读取模型输入输出节点的名称、数据类型、维度信息，搞清楚模型吃进去的是什么、吐出来的是什么。
- 数据预处理：把摄像头或者图像文件里的图像数据转换成模型输入张量所需的尺寸和数值范围（一般是640x640、归一化到0~1）。
- 推理与输出解析：执行推理，拿到输出的多维张量，从中解析出检测框坐标、类别置信度这些真正有意义的信息。
这个项目看起来平淡，但每一步都藏着坑。尤其是第2步和第4步，很多人整个模型加载成功了，输出张量也拿到手了，结果不会解析，数据从张量变成坐标这个过程就搞不清楚。下面我按实际开发顺序，把每一步都展开讲透。
2. ONNX Runtime核心Api准备与模型元数据解读
2.1 NuGet包选型：千万别搞错版本
正式开始写代码之前，先把包选对。ONNX Runtime在C#里对应的NuGet包是：
- Microsoft.ML.OnnxRuntime：CPU版本的标准包，适用于大多数工业现场。
- Microsoft.ML.OnnxRuntime.GPU：需要NVIDIA显卡和CUDA环境的GPU加速包，部署时麻烦一点，但是吞吐量高很多。
- Microsoft.ML.OnnxRuntime.Managed：仅包含托管代码，需要自行提供native DLL，一般在特殊裁剪场景才用，普通开发不用管它。
我建议直接用CPU版起步。不是因为GPU没用，而是C#上位机项目的主要瓶颈通常不在推理本身，而在于图像采集、业务逻辑的繁杂。CPU版部署简单，不存在CUDA版本匹配的问题，一套代码拷到哪都能跑。等检测耗时真的成了瓶颈，再往GPU版迁移，代码改动量其实很小，主要是会话配置那块。
版本选择上有一点必须注意：ONNX Runtime的NuGet包版本和模型导出时的opset（算子集版本）有关系，YOLOv8默认导出的opset是12或者更高，旧版本的ONNX Runtime可能会遇到不支持的算子报错。我当前用的是1.16.x以上，基本覆盖了YOLOv8的导出需求。别用太老的版本，至少1.15以上，省得踩“Unsupported operator”这个坑。
2.2 会话创建与模型文件加载
加载模型最核心的类就是InferenceSession。它不是每次推理新建一个，而是程序启动时创建一次，之后反复使用，这样可以避免反复加载模型文件的时间和内存开销。
using Microsoft.ML.OnnxRuntime; using Microsoft.ML.OnnxRuntime.Tensors; // 创建会话选项（可选） var sessionOptions = new SessionOptions(); sessionOptions.LogSeverityLevel = OrtLoggingLevel.ORT_LOGGING_INFO; sessionOptions.EnableMemoryPattern = true; // 加载模型 using var session = new InferenceSession(@"D:\models\yolov8n.onnx", sessionOptions);这段代码里两个细节值得说下。第一，模型路径最好用绝对路径或者相对当前基目录的路径，别用相对工作目录的相对路径，因为部署服务或App.config里的工作目录和你代码运行时的当前目录可能完全不同，这个坑我在现场调试时踩过好几次。第二，SessionOptions里的EnableMemoryPattern可以让ONNX Runtime在第一次推理时缓存内存分配模式，对连续推理的延迟有一点优化，但对单次推理几乎无影响，在低配工控机上多线程调用时更加明显。
2.3 用InputMetadata和OutputMetadata读取模型输入输出信息
这是整个“信息解析”的第一步——解析模型自身的结构。
// 读取输入信息 foreach (var item in session.InputMetadata) { Console.WriteLine($"输入节点名: {item.Key}"); Console.WriteLine($" 数据类型: {item.Value.ElementType}"); Console.WriteLine($" 维度: [{string.Join(", ", item.Value.Dimensions)}]"); } // 读取输出信息 foreach (var item in session.OutputMetadata) { Console.WriteLine($"输出节点名: {item.Key}"); Console.WriteLine($" 数据类型: {item.Value.ElementType}"); Console.WriteLine($" 维度: [{string.Join(", ", item.Value.Dimensions)}]"); }以YOLOv8n为例，这段代码的输出大概是这样：
- 输入节点名：images
- 数据类型：Float
- 维度：[1, 3, 640, 640]
- 输出节点名：output0
- 数据类型：Float
- 维度：[1, 84, 8400]
这个维度信息就是后面解析的关键依据。千万要养成习惯，每次拿到新模型，先把这个信息打出来看一眼，哪怕是你自己导出的模型，因为导出时的设置（是否带NMS、是否多尺度）都会改变输出维度，后面解析逻辑就完全不一样。
2.4 模型结构解析的深层含义
别看上面读元数据就几行代码，它能帮你解决一个很实际的问题：区分模型是否内置了NMS。
YOLO模型导出时有两种常见形式：
- 带NMS层：输出维度一般是[batch, num_boxes, 6]，6列分别表示x1, y1, x2, y2, score, class_id。这种模型在ONNX Runtime里跑完，结果已经是过滤掉低置信度框并且做完非极大值抑制的，后处理代码可以非常简洁，但算子兼容性问题会多一些。
- 不带NMS层（推荐）：YOLOv8默认导出就是这个，输出维度是[batch, 4 + num_classes, num_anchors]。以COCO80类为例就是[1, 84, 8400]，需要在C#层面自己做解析，提取坐标和类别概率。可控性更强，后期调阈值调NMS参数不用重新导出模型。
我推荐使用不带NMS的版本，原因是工业现场经常需要动态调整置信度阈值来适配不同产品检测需求，如果NMS内嵌在模型里，每次调阈值都得重新导出模型，太不现实。
3. 实操全流程：从读取模型到完成推理
3.1 数据预处理：图像到张量的转换
模型输入是[1, 3, 640, 640]的Float张量，每个像素的RGB值需要归一化到0~1之间，并且用NCHW（通道在前）的内存布局。
用OpenCvSharp处理图像是比较省事的做法：
using OpenCvSharp; using Microsoft.ML.OnnxRuntime.Tensors; // 读取图像 var image = Cv2.ImRead(@"D:\test.jpg", ImreadModes.Color); if (image.Empty()) { throw new Exception("图像读取失败，请检查路径"); } // 缩放至640x640 var resized = new Mat(); Cv2.Resize(image, resized, new Size(640, 640)); // 创建输入张量 var inputTensor = new DenseTensor<float>(new[] { 1, 3, 640, 640 }); // 填充张量 var data = inputTensor.Buffer.Span; int index = 0; // HWC转CHW并归一化 for (int y = 0; y < 640; y++) { for (int x = 0; x < 640; x++) { var pix = resized.At<Vec3b>(y, x); // BGR顺序 data[index++] = pix[2] / 255f; // R通道 data[index++] = pix[1] / 255f; // G通道 data[index++] = pix[0] / 255f; // B通道 } }这里有两个值得注意的细节。
第一个是颜色通道顺序。OpenCV读图默认是BGR，而YOLO训练时的颜色通道顺序是RGB，这个顺序搞反了，模型输出结果会变得非常诡异——检测框可能会出现，但类别严重错误，或者说准确率大幅下降。我在实际项目中就见过同事拿BGR数据直接喂给模型，结果类别的置信度全部偏低，排查了半天才发现是这个低级问题。
第二个是归一化方式。YOLOv8的预处理是把像素值除以255映射到0~1，没有额外的均值方差操作。如果你用的是老版本YOLOv5，某些导出代码里会有normalize层或者直接接受0~255的输入，这时候就要根据模型的实际情况来处理。判断方法很简单：看输入元数据里有没有指定均值方差，或者直接看模型文件里的预处理节点，有时候肉眼看不出来，就只能试着推理一张已知图像对比结果来验证。
3.2 执行模型推理
预处理做好之后，推理本身其实非常简洁：
using var runOptions = new RunOptions(); var inputs = new List<NamedOnnxValue> { NamedOnnxValue.CreateFromTensor("images", inputTensor) }; // 指定输出节点名，注意和模型输出元数据保持一致 using var results = session.Run(runOptions, inputs, new[] { "output0" });有人说不需要指定输出节点名，直接不传第三个参数把所有输出都拿回来。我的意见是显式指定，除非你确实需要多个输出节点。为什么？因为ONNX Runtime在未指定输出的情况下，会按模型图的拓扑顺序生成所有输出，有些模型会有一堆辅助输出，比如中间层的特征图，全拿回来徒增内存开销和转换成本。工业产品上能省的都省了。
3.3 输出张量维度解析：核心中的核心
拿到results之后，怎么从张量变成检测框，这是整个项目里最容易出问题的环节。
先看输出张量的形状。前面提到YOLOv8的输出维度是[1, 84, 8400]，84 = 4（xywh）+ 80（类别数），8400是三个尺度特征图（80x80、40x40、20x20）的网格总数之和。
解析的思路是把这个三维张量转置成[8400, 84]的形式，每个检测候选点占一行，其中前4个是框坐标，后80个是各类别得分，取最大值对应的就是预测类别，最大值就是置信度。
// 取出张量数据 var outputTensor = results[0].AsTensor<float>(); var dimensions = outputTensor.Dimensions; // [1, 84, 8400] int batchSize = dimensions[0]; int numChannels = dimensions[1]; int numAnchors = dimensions[2]; // 将Tensor数据拷贝到数组以便高效访问 var outputData = outputTensor.ToArray();这里有个性能细节：ToArray()会把整个张量浅拷贝到一维数组里，8400 * 84 = 705600个float，约2.8MB，完全在可控范围内。不要动不动就浮点索引访问，在C#里多维Tensor的索引器开销远高于直接访问一维数组，实测下来大约差3~4倍。
下面一步就是遍历每个anchor，提取坐标和类别分数，过滤掉低置信度的框。
float confidenceThreshold = 0.35f; var boxes = new List<float[]>(); var scores = new List<float>(); var classIds = new List<int>(); for (int i = 0; i < numAnchors; i++) { // 当前anchor在84个特征通道中的起始偏移 int offset = i * numChannels; // 前4个值：cx, cy, w, h float cx = outputData[offset + 0]; float cy = outputData[offset + 1]; float w = outputData[offset + 2]; float h = outputData[offset + 3]; // 从第5个开始是80个类别的置信度，找最大值 float maxScore = 0f; int maxClassId = -1; for (int cls = 0; cls < 80; cls++) { float score = outputData[offset + 4 + cls]; if (score > maxScore) { maxScore = score; maxClassId = cls; } } if (maxScore < confidenceThreshold) { continue; } // 中心点坐标转左上角右下角坐标 float x1 = cx - w / 2; float y1 = cy - h / 2; float x2 = cx + w / 2; float y2 = cy + h / 2; boxes.Add(new float[] { x1, y1, x2, y2 }); scores.Add(maxScore); classIds.Add(maxClassId); }注意一个关键点：YOLOv5系列的ONNX输出格式和YOLOv8不同，YOLOv5输出的是[1, 25200, 85]，25200 = 8080 + 4040 + 20*20，85 = 4 + 1 + 80，其中第5个是物体得分objectness，后面80个才是类别得分。而YOLOv8直接去掉了objectness，采用了解耦检测头的设计，所以通道数是4 + 80。如果你拿同一套解析逻辑去解析不同版本的YOLO，肯定出错。
判断当前模型属于哪种格式，最直接的就是看输出维度：三位的输出一般是YOLOv5格式（第二维通常在20000多），三维输出第二维如果是4+类别数则是YOLOv8格式。更稳妥的方法还是看元数据。这也是我为什么在开头强调先读InputMetadata和OutputMetadata的原因——这个习惯能帮你避免大几十个错误。
3.4 从640坐标还原到原图坐标
上面的坐标是在缩放后的640x640图像坐标系下的，如果原图不是正方形，直接拿这个坐标去画图就会偏。需要做一个简单的坐标映射。
// 原图像尺寸 int origW = image.Width; int origH = image.Height; // 缩放比例 float scaleX = origW / 640f; float scaleY = origH / 640f; for (int i = 0; i < boxes.Count; i++) { boxes[i][0] *= scaleX; boxes[i][1] *= scaleY; boxes[i][2] *= scaleX; boxes[i][3] *= scaleY; }这里的前提是做了简单的直接拉伸缩放。工业项目里还有一种更常用的方式是等比缩放加填充（letterbox），也就是把原始图像缩放到能完整放进640x640的区域内，剩余部分用灰色填充，避免图像形变导致检测精度下降。如果用了letterbox，坐标还原就多一步偏移量计算：
// letterbox换算公式 float padX = (640 - scaledW) / 2f; float padY = (640 - scaledH) / 2f; float x1 = (x1_640 - padX) / scale; float y1 = (y1_640 - padY) / scale;这个公式看起来简单，但在现场调试时很容易忘记减去padding，画出来的检测框整体偏移。我建议在写后处理时就把映射逻辑单独封装成函数，不要和解析逻辑混在一起，方便后期调整。
3.5 补充NMS后处理与最终框绘制
过滤完低置信度框之后，同样一个目标周围通常还有很多重叠的框，还需要做非极大值抑制（NMS）来合并重复检测。
用手写循环实现NMS其实不复杂，核心思路是循环选择得分最高的框，删除与其IoU超过阈值的其他框：
static List<int> NonMaxSuppression(List<float[]> boxes, List<float> scores, float iouThreshold) { var order = scores.Select((s, i) => (s, i)).OrderByDescending(x => x.s).Select(x => x.i).ToList(); var keep = new List<int>(); while (order.Count > 0) { int idx = order[0]; keep.Add(idx); var box = boxes[idx]; var toRemove = new List<int>(); for (int j = 1; j < order.Count; j++) { int otherIdx = order[j]; var otherBox = boxes[otherIdx]; float interRectX1 = Math.Max(box[0], otherBox[0]); float interRectY1 = Math.Max(box[1], otherBox[1]); float interRectX2 = Math.Min(box[2], otherBox[2]); float interRectY2 = Math.Min(box[3], otherBox[3]); float interW = Math.Max(0, interRectX2 - interRectX1); float interH = Math.Max(0, interRectY2 - interRectY1); float interArea = interW * interH; float area1 = (box[2] - box[0]) * (box[3] - box[1]); float area2 = (otherBox[2] - otherBox[0]) * (otherBox[3] - otherBox[1]); float unionArea = area1 + area2 - interArea; float iou = unionArea > 0 ? interArea / unionArea : 0; if (iou > iouThreshold) { toRemove.Add(j); } } for (int j = toRemove.Count - 1; j >= 0; j--) { order.RemoveAt(toRemove[j]); } order.RemoveAt(0); } return keep; }NMS的IoU阈值一般取0.45左右比较合适。这个值影响的是重叠框的合并程度，设太大会有大量重叠框残留，设太小又可能把相邻的多个真实物体错误合并。比如检测紧密排列的工件时，可以适当调到0.4，检测稀疏场景可以放宽到0.5。
拿到keep集合之后，就可以画出最终的检测框，并把类别名称、置信度标注上去。这里类别名称需要你自己准备一个字符串数组，按COCO数据集类的顺序排好。比如第0个是person，第1个是bicycle，等等，顺序不能错。
4. 常见问题与排查技巧实录
4.1 模型加载失败：缺少依赖DLL
ONNX Runtime的NuGet包会带上native DLL，但不同的包版本和Target Framework之间可能存在问题。最常见的现象是加载模型时抛出异常：
- BadImageFormatException：项目是x86目标，但NuGet包默认带的native DLL是x64的，或者反过来。排查思路很简单：把项目的平台目标改成x64，或者安装对应架构的ONNX Runtime包版本，不要用AnyCPU跑带native代码的库。尤其在C#上位机项目里，如果其他依赖库要求x86，和ONNX Runtime就会出现冲突，这时候得评估整个系统的架构一致性。
- DllNotFoundException：这个通常在部署到干净的机器上时出现，开发机没问题，拷到客户机器就崩。原因是系统缺少Visual C++运行库。解决办法是在部署包中带上对应的VC++ Redistributable，或者把所需的DLL一起复制到exe目录。
这类问题有个通用排查手法：用Dependencies工具（或者简单的dumpbin）查看生成的exe依赖了哪些native DLL，然后逐个确认是否都存在于运行目录。
4.2 输入张量shape不匹配
ONNX Runtime在Run时如果发现输入Tensor的维度和模型声明的输入维度不一致，会直接抛异常：
- 错误信息类似“Unexpected input data type. Actual: (NCHW=1,3,224,224), Expected: 1,3,640,640”。
解决方法是严格按照InputMetadata里的Dimensions去创建Tensor。如果遇到动态维度（-1表示可变），加载元数据时你会看到-1，此时要保证运行时实际填充的值在合理范围内。还需要注意InputMetadata.ElementType，如果模型输入是INT8，你却塞Float，也会直接报错。
4.3 输出全为零或者输出维度与预期不符
这个问题非常常见，尤其是从别的项目里抄了一段解析代码，却用到了不同版本的YOLO模型上。
- 如果你解析YOLOv5的[1, 25200, 85]却按[1, 84, 8400]的方法去读，结果不仅是出错，严重时可能数组越界或者访问到不连续内存。
- 如果你解析YOLOv8的[1, 84, 8400]却按25200的维度遍历，锚点数量对不上，检测框数也会对不上，表现是“检测结果稀疏、大量目标丢失”。
现象是：置信度过滤后的框要么全是0，要么几乎框不住目标，要么框的位置乱七八糟。这时候先别急着改代码，回到最前面打印InputMetadata和OutputMetadata，弄清输出的真实形状再改解析逻辑。我无数次验证过，这个流程走下来，90%的问题都能解决。
4.4 预处理细节导致精度下降
有朋友反馈模型加载正常、推理也不报错，但检测精度明显比Python端低一截，比如漏检多、置信度低。这多半是预处理细节没对齐：
- 通道顺序BGR/RGB混了，上面已经提过。
- 归一化方式错了，比如没有除以255，或者错误地减均值除以标准差。
- 图像尺寸缩放方式不一致，比如模型训练时用的是letterbox，推理时你却直接拉伸，导致目标变形。
- 数据类型不对，f32和f64混用偶尔也会造成微小误差，但现代PC上影响不大，重点是前三个。
一个特别实用的排错方法：拿同一张图，在Python端跑一遍，记录输出结果里某个框的坐标和置信度，再在C#端跑一遍，对比差异。如果C#端的坐标偏差很小但置信度明显低，基本可以否定是解析问题而是预处理问题。如果坐标都差得离谱，就要检查缩放和坐标还原逻辑。
4.5 推理耗时过高
ONNX Runtime CPU版跑YOLOv8n是很快的，640x640输入在普通台式机上单次推理大约20~40毫秒。如果你测出来一次跑了几百毫秒，先别怀疑库，检查这几件事：
- 是否开了多线程调试（Visual Studio的调试模式下性能会受影响）。
- 是否每个检测周期都在重新new InferenceSession，这是大忌，会话必须复用。
- 是否频繁调用ToArray()和多维索引器，尽量用一维数组的span访问。
- 系统是否有其他高负载程序抢占CPU。
如果对性能要求更高，可以将ONNX Runtime GPU包和CUDA环境加上。GPU推理在显卡支持的前提下能压到5毫秒以内，但部署复杂度带来的边际成本你需要自己权衡。
4.6 内存持续增长
用ONNX Runtime做循环推理时，如果不注意释放资源，内存会缓慢增长。核心原则是：
- InferenceSession用完后要Dispose，但不要在推理循环里反复创建销毁。
- Run的返回值results是IDisposable，用完务必Dispose，最好是using语句包裹。
- 每次创建DenseTensor，用完就不需要手动释放，它只是托管对象，但大量操作它时要注意GC压力。
我把这个排查点放在最后，是因为内存问题往往不容易暴露，现场跑几天才出现一次崩溃，很难定位。建议用性能分析器（比如dotnet-counters）在长时间压力测试时观察内存曲线，看是否存在持续增长。
5. 线程模型设计与工程化落地要点
5.1 C#上位机中的线程安排
在WinForm或WPF上位机程序里，推理绝对不能放在UI线程里跑，否则界面会卡死，用户体验极差。
我的做法是设计一个独立的推理线程，图像采集线程把图像塞进队列，推理线程从队列取出图像，执行预处理、推理、后处理，最终通过事件或线程安全队列把检测结果推送给UI线程渲染。
核心伪代码如下：
// 图像队列（线程安全） ConcurrentQueue<Mat> imageQueue = new ConcurrentQueue<Mat>(); CancellationTokenSource cts = new CancellationTokenSource(); // 推理线程 Task.Run(() => { using var session = new InferenceSession(modelPath); while (!cts.IsCancellationRequested) { if (imageQueue.TryDequeue(out Mat frame)) { var boxes = RunInference(session, frame); OnDetectionCompleted?.Invoke(boxes); } else { Thread.Sleep(5); } } });这里有个容易被忽视的问题：inference session在多个线程间是否可以并发调用？ONNX Runtime的InferenceSession默认不是线程安全的，如果多个线程同时调Run，需要加锁，或者每个线程各建一个session。但在我的架构里只有一个推理线程，所以这个问题就自然规避了。
5.2 模型文件的部署路径与版本管理
工业软件部署时，模型文件不能散落在桌面或随意路径。我习惯的做法是放在exe同级的models目录下，并在代码里用AppDomain.CurrentDomain.BaseDirectory拼路径：
string modelPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "models", "yolov8n.onnx");这样部署时只需要把models文件夹整体拷到安装目录，不会出现路径失效。
模型的版本管理同样重要。迭代模型时，旧模型和新模型的输出维度可能不同，接口参数也可能变化。建议在模型文件名中加入版本标识，比如yolov8n_v3.onnx，并在配置文件中指定当前使用的模型文件名，这样现场切换模型只需要改配置文件，不用改程序。
5.3 写一个简单的模型信息解析工具
最后补一个实用的小工具。因为读取模型元数据这个动作太常用了，我平时会把这些逻辑封装成一个控制台小工具，拿到任何ONNX模型都能立刻解析并打印输入输出信息，还能把输出Tensor的shape常量打印出来供解析代码参考。
static void Main(string[] args) { if (args.Length < 1) { Console.WriteLine("Usage: OnnxInfoTool <model.onnx>"); return; } using var session = new InferenceSession(args[0]); Console.WriteLine("=== Inputs ==="); foreach (var input in session.InputMetadata) { Console.WriteLine($"{input.Key}: {input.Value.ElementType}, dims=[{string.Join(",", input.Value.Dimensions)}]"); } Console.WriteLine("=== Outputs ==="); foreach (var output in session.OutputMetadata) { Console.WriteLine($"{output.Key}: {output.Value.ElementType}, dims=[{string.Join(",", output.Value.Dimensions)}]"); } }这个工具20行代码，但它的价值极高。有了它，每次拿到模型，先跑一遍，再写解析逻辑，整个过程就能按图索骥，不再抓瞎。
根据我的个人经验，C#和ONNX Runtime这套组合在工业场景下非常稳，但要真正跑起来，认真对待模型元信息永远比试错优先级更高。拿到模型先读元数据，你会少走太多弯路。
这个项目往后还可以扩展的方向挺多，比如接入摄像头实时流、加上区域检测逻辑、把检测结果通过Modbus/TCP总线上报给PLC，甚至和运动控制卡联动做自动分拣。C#生态里的视觉检测上位机基本就是这套玩法，把模型加载和信息解析这两个底座打牢实了，上面再盖什么楼都不慌。
