OpenCVSharp连通性检测实战：从ConnectedComponentsWithStats到工程封装

有一个深夜，我在做一批零件外观检测程序的联调，同一样品连续跑了两遍，检测出来的“缺陷区域”数量却差了一百多个。查了半天，问题出在某个分支里把灰度图转成了彩色图，下游代码还在按单通道逻辑访问像素。这种低级错误其实很常见，而它暴露出来的本质问题，是对连通性检测理解决不够透——它不是一个“扔张图进去、出来一堆结果”的现成功能，它的输入、数据结构、参数约定都藏着不少细节。

今天这篇就用 OpenCVSharp 着重聊连通性检测。如果你用过 C++ 或者 Python 版的 OpenCV，再转过来写 C#，最舒服的一点就是 OpenCvSharp 的 API 几乎原样对齐了原生 OpenCV，ConnectedComponentsWithStats、connectedComponents 这一套都能直接映射过来。但舒服归舒服，真正落到自己的业务里，从图像类型、通道排布到标签数据的读取方式，处处是坑。

这篇适合以下几类人：刚开始接触 OpenCVSharp、想用连通性分析做目标计数或区域提取的；已经在用但被 labels、stats 这些返回值搅得头痛的；以及想在工程里把连通域检测做成一个稳定工具函数、少踩几次重复坑的。我会按照“概念 -> Demo -> 数据结构 -> 场景化过滤 -> 实战排坑 -> 工程封装”的顺序讲，尽量让每个结论都能直接复现。

1. 连通性检测在图像分析里到底扮演什么角色

1.1 从“一堆像素”到“一个个物体”的转变

图像经过阈值化、边缘检测或颜色筛选之后，得到的往往是一个个离散的像素集合。以最常见的二值图为例，白色像素代表我们关心的目标，黑色像素是背景，但像素本身是没有“物体”概念的。我们想知道图里到底有几个目标、每个目标大概有多大、每一块有没有独立边界，就必须把这些像素按照空间上的相邻关系分组。

连通性检测干的就是这件事。它把“相互连通的白色像素”归为同一个区域，给每个区域分配一个唯一的编号标签，再附加统计信息。这种操作在计算机视觉领域被称为连通区域标记，英文叫 Connected Component Analysis，简称 CCA。你盯着屏幕看时，能一眼分清图片里有三个圆、两个矩形，是因为人脑天然具备空间分组能力；而计算机没有这个能力，连通性检测就是补上这层分组能力最基础、最常用的一把钥匙。

用生活里的场景来类比：一箱子积木倒在地上，你按“有没有碰在一起”把它们分成几堆，碰在一起算一堆，不碰就算另一堆。连通性检测干的正是这个“碰不碰在一起”的判断，只不过判断对象是像素，标准则是像素之间是否共享边界或角点。

1.2 OpenCVSharp 里连通性检测的三种常见打开方式

在 OpenCVSharp 中，连通性检测的功能主要落在三个 API 上：

• Cv2.ConnectedComponents：只做区域标记，输出一张和原图同样大小的标签图。适合最基础的“数个数”场景。
• Cv2.ConnectedComponentsWithStats：除了标记图之外，还会输出每个区域的边界框、面积、质心等统计信息。这是实际项目中最常用、最值得优先掌握的版本。
• Cv2.ConnectedComponentsWithAlgorithm：允许显式指定使用的算法类型，在性能极端敏感的场景下会用到。

这三个函数在输出层面有一点相同：标签图里像素值不再代表灰度，而是代表“这个像素属于第几个区域”。如果你打开一张标签图直接显示，看到的通常是黑色背景上随机深浅的形状，那并不代表真实的灰度信息，而是区域编号的可视化结果。

我建议初学者把主要精力放在 ConnectedComponentsWithStats 上。因为工程里几乎不存在“只需要计数”而完全不需要区域位置和面积的情况。哪怕是简单的细胞计数，你也往往需要统计每个细胞的大小、位置、颗粒度，单纯数个数只是最粗糙的第一步。

2. 跑通第一个连通性检测 Demo：从载入图像到可视化结果

2.1 环境准备和 NuGet 包选择

在动手写代码之前，先把环境准备踏实，这一块翻车率反而最高。新建 .NET 项目之后，通过 NuGet 安装以下两个包：

• OpenCvSharp4：核心程序集，包含 Cv2 静态类以及各类 Mat、Rect、Scalar 类型。
• OpenCvSharp4.runtime.win：Windows 运行库。它会自动把 OpenCV 原生依赖文件复制到输出目录。

如果你的项目要部署到 Linux 服务器上跑，就不要用 OpenCvSharp4.runtime.win，而是安装 OpenCvSharp4.runtime.ubuntu 之类的对应包，或者直接在服务器上用 OpenCV 的 CI 构建产物做本地依赖。这个细节在开发机上一切正常、部署后却报 DllNotFoundException 时尤其值得排查。

2.2 二值化预处理 —— 连通性检测的输入要求

聊完环境，直接上一个最小 Demo。假设我有一张工件表面的灰度图 sample.jpg，目标是统计图中有几个明显的瑕疵区域。第一步要先把灰度图变成二值图。

csharp复制using OpenCvSharp;

Mat gray = new Mat("sample.jpg", ImreadModes.Grayscale);
Mat binary = new Mat();
Cv2.Threshold(gray, binary, 0, 255, ThresholdTypes.Otsu | ThresholdTypes.Binary);

为什么不能把原始灰度图直接喂给连通性检测？核心原因在于，连通性检测处理的是“是否属于前景”的二值语义。灰度图里的每个像素有 0 到 255 共 256 种取值，如果直接当作输入，算法无法区分“低灰度目标”和“背景中较暗的干扰”。OpenCV 官方接口在设计时也没有规定死必须输入二值图，但大多数场景下直接传入灰度图得到的结果并不可靠，甚至因为噪声过多导致区域数量爆炸。

所以正确姿势是：先用 Cv2.Threshold、Cv2.AdaptiveThreshold、Cv2.Canny 之类的操作，把非黑即白的前景信息提取出来。一般推荐 Otsu 自动阈值，对于光照相对均匀的图像效果非常稳，我上面代码里就是这么处理的。

如果你处理的是彩色图，想只根据颜色提取前景，建议用 Cv2.InRange 或 Cv2.Split + 通道阈值，先把目标颜色区域转成二值图，再送去连通性检测。这个问题看着不起眼，但在实际项目里非常普遍——很多人拿着一张 BGR 彩色图直接 Cv2.CvtColor 转灰度，再走阈值，结果是背景和目标灰度差异不大，检测效果稀烂。

2.3 调用 ConnectedComponentsWithStats 跑通全流程

二值图准备好之后，进入连通性检测的主体调用：

csharp复制Mat labels = new Mat();
Mat stats = new Mat();
Mat centroids = new Mat();

int numLabels = Cv2.ConnectedComponentsWithStats(
    binary,
    labels,
    stats,
    centroids,
    PixelConnectivity.Connectivity8,
    MatType.CV_32S);

Console.WriteLine($"检测到区域数量（含背景）: {numLabels}");

这段代码里的几个参数，第一次接触的人很容易产生疑惑：

• labels 是输出的标签图，尺寸与输入相同，每个像素存放所属区域编号，编号从 0 开始，0 代表背景。
• stats 按行存放每个区域的外接矩形和面积信息，每一行对应一个区域编号，具体字段含义下一节详细讲。
• centroids 按行存放每个区域的质心坐标，类型为浮点。
• PixelConnectivity.Connectivity8 表示 8 连通，即上下左右加上四个对角方向的像素都算相邻。
• MatType.CV_32S 是标签图的数据类型，带符号 32 位整数。这个选择不是随意的，后续我会重点解释为什么不用 CV_16U。

拿到结果后，如果只是想在窗口里看效果，我建议把标签图连同一个简单的可视化一起展示，不要把 labels 当作普通灰度图直接显示。最省事的方式是将其转成彩色：

csharp复制Mat output = new Mat();
Cv2.CvtColor(gray, output, ColorConversionCodes.GRAY2BGR);

for (int i = 1; i < numLabels; i++)
{
    int area = stats.At<int>(i, (int)ConnectedComponentsTypes.Area);
    if (area < 100)
        continue;

    int left = stats.At<int>(i, (int)ConnectedComponentsTypes.Left);
    int top = stats.At<int>(i, (int)ConnectedComponentsTypes.Top);
    int width = stats.At<int>(i, (int)ConnectedComponentsTypes.Width);
    int height = stats.At<int>(i, (int)ConnectedComponentsTypes.Height);

    Rect box = new Rect(left, top, width, height);
    Cv2.Rectangle(output, box, new Scalar(0, 0, 255), 2);
}

using (new Window("Connected Components", output))
{
    Cv2.WaitKey(0);
}

这里特别提醒一句，遍历区域时我特意把下标 i 从 1 开始。因为整个标签体系里 0 号区域永远是背景，如果从 0 开始遍历，你会把一个覆盖全图的巨大背景框画出来，看起来就像整个图像都被框住了，非常迷惑。

3. 数据结构和参数细节：理解 labels、stats、centroids 里的内容

3.1 labels 里存的是“编号”而不是灰度

labels 最容易被刚接触的人误读。它是 Mat，但里面的像素值不是亮度，而是区域编号。比如 labels.At<int>(y, x) 返回 3，表示坐标 (x, y) 处的像素属于第 3 号连通区域。

读取标签图时要注意数据类型。我在上面指定了 MatType.CV_32S，这意味着每个像素是一个 int。如果你在代码里用 labels.At<byte>(y, x) 去取，会得到一个完全错误的数值，甚至抛出异常。OpenCvSharp 的泛型 At<T> 方法对类型相当敏感，指定的类型和实际 Mat 类型不一致时，产生的结果不具备任何可比性。所以请记住：用 At<int> 配合 CV_32S。

为什么标签图推荐 CV_32S，这和一个隐藏边界条件有关。用 CV_16U（无符号 16 位整数）时，上限是 65535，当一个超大图中连通区域数量超过这个值，编号就会溢出，导致多个区域共享同一个编号，后面的分析全乱。实际产品里虽然很少碰到六万多个连通区域，但处理高噪声背景或者非常细碎的纹理图时并不是完全不可能。直接用 CV_32S 一劳永逸，内存开销多一倍而已，换来的是确定性，这笔账划算。

3.2 stats 的五列含义与逐行取值技巧

stats 是一个二维矩阵，行数等于区域数量（含背景 0 号区域），列数固定为 5。OpenCvSharp 中枚举常量已经帮你排好了顺序，我建议直接用枚举而不是写死数字下标，可读性和可维护性都会更好：

这里有一个很容易混淆的细节：Left 和 Top 是矩形左上角坐标，而 Width 和 Height 是矩形尺寸，不是右下角坐标。如果你需要右下角坐标，要自己算 left + width 和 top + height。不少新人在筛选区域时顺手把 Width 当 X 方向末尾坐标来用，画出来的框要么偏移一个身位，要么越界。

读取 stats 数据时，比较直观的做法是逐行处理。比如只关心面积大于一定阈值的区域，可以这样写：

csharp复制for (int i = 1; i < numLabels; i++)
{
    long area = stats.At<int>(i, (int)ConnectedComponentsTypes.Area);

    if (area >= minArea)
    {
        // 处理该区域
    }
}

在数据量极大的场景下，逐行 At<int> 的性能不如整块拿数据。不过那是后话，先把语义搞对，性能优化永远跑在正确性后面。另外要注意，Area 的返回值是像素数量，反映的是目标在图像中占据的面积，如果要做真实物理尺寸估算，得结合相机的像素尺寸标定，这一步和连通性检测本身无关。

3.3 centroids 的精度和类型坑

centroids 是每个连通区域的质心坐标，它是一个二维矩阵，行数等于区域数量，列数为 2，第一列是 X 坐标，第二列是 Y 坐标。

在 OpenCV 的 C++ 接口中，centroids 的类型通常是浮点型，输出为 double 或 float 视具体算法实现而定。OpenCvSharp 里读取时，我习惯用 centroids.At<double>(i, 0) 来取 X 坐标，用 centroids.At<double>(i, 1) 来取 Y 坐标。如果发现质心坐标完全错乱，第一反应应该是检查读取类型是不是 float 和 double 用混了。

质心在可视化时非常有用，很多场景需要在每个目标中心画个点，用来验证检测结果是否正确。下面这行就是把质心画出来的标准写法：

csharp复制int cx = (int)Math.Round(centroids.At<double>(i, 0));
int cy = (int)Math.Round(centroids.At<double>(i, 1));
Cv2.Circle(output, new Point(cx, cy), 3, new Scalar(0, 255, 0), -1);

3.4 4连通还是8连通：什么时候改默认值

OpenCvSharp 中的 PixelConnectivity 有两个常用取值：Connectivity8 和 Connectivity4。默认使用 8 连通时，上下左右及四个对角都视为相邻；4 连通则只把上下左右视为相邻。

这个选择直接决定了目标分隔的粒度。比如两个矩形沿对角线方向顶角相碰，8 连通会把它们视为同一个整体，4 连通则会视作两个独立区域。所以并非 8 连通总是更好，具体看你的业务语义。

给个经验法则：

• 如果目标边缘圆润、颗粒状明显，比如细胞、粉尘颗粒，优先用 8 连通，区域结果更完整。
• 如果目标形状偏长条形，或者画面中有大量斜向相接的干扰，优先用 4 连通，可以有效减少误粘连。
• 如果处理的是字符、笔迹这类语义明确的图像，OCR 预处理时 8 连通更合适，因为笔画转折处经常是斜向相邻的，4 连通会把一个字拆成多个部件。

实际问题里没有标准答案，最好把连通方式做成一个可配置参数，现场数据测试时多切几次看效果。

4. 从连通区域到有用信息：面积过滤与目标提取

4.1 过滤掉小噪点：面积阈值的经验值和两种策略

二值化之后，图像上无可避免会有一些细小的噪点，它们本身也是“连通区域”，如果不过滤，会直接干扰计数和区域统计。最简单的过滤手段就是面积阈值。

面积阈值的选取有两条路线。一种是固定值法，比如 area >= 100；另一种是相对比例法，比如取最大区域面积的 10% 作为阈值。固定值法简单粗暴，适合背景相对干净、目标大小差异不大的场景。相对比例法更稳健，适合目标尺寸变化范围大的场景，比如零件编号印刷检测中，不同编号字符的大小会有波动，固定阈值很容易误删或者漏删。

我个人更倾向于把这两种方式结合：先算全部区域面积，取最大面积作为参考，然后设置一个 minAreaRatio 参数（比如 0.05），低于该比例的区域直接剔除。这样即使不同批次的图像分辨率发生变化，也不需要频繁改代码。

csharp复制int maxArea = 0;
for (int i = 1; i < numLabels; i++)
{
    int area = stats.At<int>(i, (int)ConnectedComponentsTypes.Area);
    if (area > maxArea)
        maxArea = area;
}

double minArea = maxArea * 0.05;

for (int i = 1; i < numLabels; i++)
{
    int area = stats.At<int>(i, (int)ConnectedComponentsTypes.Area);
    if (area < minArea)
        continue;

    // 剩下的区域就是需要关注的候选目标
}

这里要说一个容易翻车的点：如果图像中根本没有目标，只有一个背景区域，那背景区域的面积几乎等于整个图像，最大面积会异常偏大，所有前景区域反而都会被过滤掉。针对这种情况，代码里最好加一个判断，如果 numLabels 等于 1（只有背景），就直接返回空结果，避免业务侧做无意义计算。

4.2 基于边界框的后续裁剪和处理

过滤完噪点之后，stats 里的外接矩形信息可以非常自然地对接后续流程。常见需求是把每个连通区域单独裁剪出来，保存成小图，或者送进 OCR、分类模型。

在 OpenCvSharp 中，裁剪区域用 Cv2.GetRectSubPix 或直接通过 Mat 的 [rect] 索引完成。这里有一个安全细节：stats 给出的外接矩形坐标虽然是由 OpenCV 计算出来的，理论上不会越界，但当图像有抗锯齿边缘或 Canny 输出时，极端情况下矩形边界还是可能超出图像范围。稳妥的做法是裁剪前做一次 Intersect 运算：

csharp复制Rect full = new Rect(0, 0, gray.Width, gray.Height);
Rect roi = new Rect(left, top, width, height).Intersect(full);

Mat cropped = new Mat(gray, roi);

这行代码的作用是把 ROI 限制在图像实际范围内，防止边界问题导致 OpenCVException。这个细节虽然小，却能省掉不少线上崩溃排查的时间。

4.3 把检测结果用伪彩色铺到原图上，便于验收

工程交付时最常被业务方催问的一句话是“你的检测准不准”。只输出一堆数字没人信，最好的验收方式是直接把每个检测到的目标在原图上圈出来，并标注编号。前面已经画过矩形框，这里再补充一个编号标注：

csharp复制Cv2.PutText(
    output,
    $"{i}",
    new Point(left, top - 5),
    HersheyFonts.HersheySimplex,
    0.5,
    new Scalar(255, 255, 0),
    1,
    LineTypes.Link8);

当我处理多目标的图像时，会在每个连通区域上绘制不同颜色的框，这样一眼就能看出哪些区域被合并、哪些被拆开了。如果你觉得手动分配颜色麻烦，可以参考下面这段伪随机颜色生成：

csharp复制private static Scalar RandomColor(Random rand)
{
    return new Scalar(
        rand.Next(50, 256),
        rand.Next(50, 256),
        rand.Next(50, 256));
}

伪彩色只能用于结果展示，绝不能用于算法逻辑判断。颜色信息已经是对原图的二次加工，一旦拿它做后续分析，很容易引入不透明度、通道顺序等污染项，给 bug 制造伏笔。

5. 生产环境里容易踩的坑：从图像类型到数量偏移

5.1 图像类型不对导致的静默失败

连通性检测接收的图像类型在 OpenCV 文档里写得很死：8 位单通道图像、且是二值图。但实际调用时，输入 CV_8UC3（三通道彩色）并不会直接引发异常，OpenCV 内部会先尝试处理，结果往往完全不可控，或者只在某些版本里抛出异常。

我调试过的案例中，输入图像在某个分支里被 Cv2.CvtColor 转成了 BGR 彩色图已经不是一次两次。这种 bug 的特点是，连通性检测仍然返回一个看似合理的结果，但区域数量和位置信息与实际预期完全对不上。排查的方式也简单，在调用函数前显式断言类型：

csharp复制if (binary.Type() != MatType.CV_8UC1)
{
    throw new InvalidOperationException($"输入类型不是 CV_8UC1，当前是 {binary.Type()}");
}

把这种防御性检查养成习惯，能省下大量联调时间。图像处理流水线越长，中间类型越容易丢失控制，与其事后靠断点去找，不如在关键入口卡一道保险。

5.2 背景标签0：计数偏移一多半的教训

前面提到过，0 号区域永远是背景。但“背景”这个概念在不同阈值方向下会发生变化。使用 ThresholdTypes.Binary 时，大于阈值的像素置为白色（前景），小于阈值的置为黑色（背景）；而使用 ThresholdTypes.BinaryInv 时正好反过来，原本不感兴趣的区域反而成了前景。

这就导致一个非常隐蔽的坑：当你用反向阈值时，整个大面积背景会成为 0 号区域上方的 1 号区域，真正的目标对象则会变成编号靠后的区域。不熟悉这个逻辑的人，常常会发现区域数量比实际目标数量多一个，而且多出来的是一个近乎覆盖整个画面的巨大矩形。这并不是算法出 bug，而是背景被当成数据参与了分析。

处理办法是对面积分布做直观判断，或者一开始就明确语义。如果是“黑色背景上找白色目标”，用 ThresholdTypes.Binary；如果是“白色背景上找黑色目标”，用 ThresholdTypes.BinaryInv。不管哪种方向，遍历时都要从 1 开始，并在过滤阶段把面积特大的背景候选区单独处理。

5.3 性能取舍：逐像素访问 vs 批量操作

连通性检测本身的算法效率已经很高，但拿到 labels 之后如果还要做逐像素遍历，性能隐患就来了。比如要对每个区域做掩膜提取，很多人会写成两层循环逐像素判断 labels.At<int>(y, x) == i，这在图像尺寸很大时非常慢，毕竟 At<T> 方法每次调用都有边界检查和类型转换开销。

两个优化方向：

• 提前准备好一张 bool 或 byte 的掩膜图，用 Cv2.InRange 配合标签图快速提取属于某个区域的前景。
• 如果确实需要逐像素访问，推荐用 Mat.GetArray 一次性把数据拷贝到托管数组里再冲刷，或者使用 unsafe 代码直接定位内存。

csharp复制int rows = labels.Rows;
int cols = labels.Cols;
int[] labelData = new int[rows * cols];
labels.GetArray(out labelData);

for (int y = 0; y < rows; y++)
{
    for (int x = 0; x < cols; x++)
    {
        int id = labelData[y * cols + x];
        // 业务处理
    }
}

这个思路和直接逐像素访问 At<T> 相比，速度提升非常明显，而且不用碰指针，安全性和可维护性都更好。对于大图或者高帧率视频，强烈建议一开始就采用这种模式。

5.4 处理粘连目标时，连通性分析解决不了的问题

连通性检测最尴尬的场景，就是两个目标物理上连在了一起却仍被期望识别成两个对象。比如两个圆形细胞紧贴在一起，图像上它们的边缘已经融合成一个葫芦形区域，连通性分析只能告诉你是“一个连通区域”，拆分根本做不到。

针对粘连分离，通常的出路是距离变换 + 分水岭算法。距离变换可以计算每个前景像素到背景的最近距离，分水岭算法能根据这个距离图把粘连的物体从“山谷”处切开。OpenCvSharp 中对应 Cv2.DistanceTransform 和 Cv2.Watershed。这套组合对颗粒状目标效果显著，但参数调起来需要一个适应过程，不是一上来就能用的。

我的建议是，判断是否采用分水岭之前，先评估原始图像分辨率。如果目标粘连严重、边界模糊，分水岭也很难有理想效果；不如重新调整拍摄方案或者预处理方法。连通性检测只是分析流程中的一个组件，把它当作万能拆分工具来用，只会让自己陷入不断调参的泥潭。

6. 把连通性检测封装成通用工具方法

把连通性检测封装成可复用工具函数，是我在实际项目里受益最大的一个习惯。不封装的痛点是，业务代码里到处是“先二值化、再调用、再遍历 stats”的样板代码，一旦需要调整连通方式或面积过滤逻辑，就得全局搜索、逐个修改。

一个足够用的封装，应当接受灰度图或二值图，返回一个包含“有效区域”结果的对象集合：

csharp复制public class ConnectedComponentResult
{
    public int Label { get; set; }
    public Rect BoundingBox { get; set; }
    public int Area { get; set; }
    public Point2d Centroid { get; set; }
    public Mat Mask { get; set; }
}

public List<ConnectedComponentResult> ExtractRegions(Mat binary, int minArea)
{
    var results = new List<ConnectedComponentResult>();

    if (binary.Empty())
        return results;

    Mat labels = new Mat();
    Mat stats = new Mat();
    Mat centroids = new Mat();

    int numLabels = Cv2.ConnectedComponentsWithStats(
        binary,
        labels,
        stats,
        centroids,
        PixelConnectivity.Connectivity8,
        MatType.CV_32S);

    for (int i = 1; i < numLabels; i++)
    {
        int area = stats.At<int>(i, (int)ConnectedComponentsTypes.Area);
        if (area < minArea)
            continue;

        results.Add(new ConnectedComponentResult
        {
            Label = i,
            BoundingBox = new Rect(
                stats.At<int>(i, (int)ConnectedComponentsTypes.Left),
                stats.At<int>(i, (int)ConnectedComponentsTypes.Top),
                stats.At<int>(i, (int)ConnectedComponentsTypes.Width),
                stats.At<int>(i, (int)ConnectedComponentsTypes.Height)),
            Area = area,
            Centroid = new Point2d(
                centroids.At<double>(i, 0),
                centroids.At<double>(i, 1))
        });
    }

    return results;
}

这个封装最大的好处是把“遍历从 1 开始”“面积过滤”“结果结构”等经验性细节固化在一个地方。业务侧只需要关心 BoundingBox、Area 这些语义化字段。后续如果要换成其他连通性算法，也只需要改这一个函数。

封装时还需要注意一个点：如果业务中要基于该区域做进一步裁剪，最好保留一个 Mask 属性，可以基于 labels 图导出，但不要无条件保留，因为每个区域一个掩膜会增加内存。用到哪个区域再实时生成，更划算。

再聊一聊我自己的习惯：封装完这个工具函数之后，我通常会写一个独立的小 Demo，固定用一张包含多个目标的测试图去验证若干参数组合。这张图不会随便选，要有意识地包含大小差异大的目标、贴边目标、疑似噪声点，只有这类图才能把边界情况暴露出来。很多项目调参调到后期，才发现测试图和真实数据分布差异太大，导致现场效果崩盘，这属于测试集设计问题，不是算法问题。

最后再补充两个我自己平时用得很顺的小技巧

第一个技巧是，想要快速理解 labels 里每个区域的形状，不要直接看数字，而是把第 i 个区域单独提取成掩膜，叠到原图上。比如在调试字符分割时，我经常逐个区域看掩膜，确认字符的断笔是否被完整保留。方法也很简单，用 Cv2.InRange(labels, new Scalar(i), new Scalar(i)) 就能得到一个只有第 i 个区域是白色、其余全黑的掩膜图，干净利落。

第二个技巧是，当你觉得连通性检测的结果有异常时，先用 Cv2.MinMaxLoc(stats) 或直接打印 stats 矩阵的前五行，看看字段值是否符合直觉。我见过大量所谓的“结果不对”，最终都指向区域顺序、背景标签、最小面积阈值这类初级问题，根本轮不到算法层面。数据打印一次，往往能省掉一整天的猜想。

连通性检测在 OpenCVSharp 里的用法并不复杂，真正值得花心思的是理解它的数据结构和边界条件。把 Demo 跑通只是起点，能在真实项目中稳定输出、快速排坑，才是把这个基础能力真正吃透的标志。希望这篇整理能让你在后续开发里少走几步弯路。