企业官网建设流程全解析

简介：本资源是一个基于C#与OpenCvSharp实现的文字图像线条去除实战项目，面向图像处理初学者、OCR预处理开发者及文档数字化相关技术人员，聚焦解决扫描件或低质量文字图像中干扰识别的横线、竖线、表格线等结构噪声问题。压缩包共94个文件，包含10个核心C#源码文件（如frmMain.cs）、1个Visual Studio解决方案（.sln）、6个可执行程序（.exe）及配套配置（.config）、资源（.resx）、动态库（.dll）和调试符号（.pdb），整体体积35.46MB，结构完整，支持开箱即用与二次开发。已有163人学习下载，项目代码组织清晰，涵盖二值化、形态学腐蚀/膨胀、霍夫直线检测、连通域分析等关键步骤的完整实现逻辑，并集成实际测试图像（png/jpg）与可视化主界面，便于理解算法流程、调试参数效果及迁移至自有OCR流水线。 最近在做一个票据识别的小工具，遇到一个极其典型的问题：扫描件里横线、格线、下划线跟文字搅在一起，OCR识别率惨不忍睹。正常一段文字识别率95%以上，一旦背景里有线条干扰，直接掉到60%甚至更低。网上搜了一圈，中文资料大多只有一张效果图，代码要么是Python版要么干脆没有。我用C#配合OpenCvSharp把这套“去除文字中的线条”的方案完整做了一遍，从方案选型到参数调优到踩坑记录，全部整理在下面，供同样用.NET做图像预处理的朋友参考。

这个方案的核心思路其实只有两步：先用形态学操作把“线条”单独提取出来，再通过图像修复算法把这些线条从原图上“擦掉”。听起来简单，实际做的时候坑不少，尤其是线条和文字交叉的位置，处理不好文字就会缺胳膊少腿。这篇文章会把这套流程的完整代码、每个参数背后的原理、以及我遇到的各种问题全部讲清楚。

1. 场景分析与方案选型

1.1 哪些业务场景需要“去线条”

这类需求在真实业务里出现频率相当高，我至少接触过四类典型场景：

第一类是单据扫描件。报销单、发票、银行回单上都有预印的表格线，这些线在扫描时经常和手写体或者打印体文字重叠。识别程序如果不做预处理，会把横线识别成文字的一部分，或者干脆把文字切断，结果字段对不上号。

第二类是信纸底纹。很多合同、协议扫描件的背景是带横线或格线的信纸，尤其是拍照上传的版本，线条和文字混在一起，识别效果非常差。这类图像的线条通常颜色偏浅，属于水印性质的干扰，比单据上的深色表格线好处理一些，但光线不均的情况下依然头疼。

第三类是证件复印件。身份证、银行卡复印件上经常有“仅供xx使用”的水印字，还有背景的底纹网格。这种水印虽然不是线条，但处理思路是相通的，这篇文章讲的方法改一改参数就能用。

第四类是试卷和答题卡识别。印刷体试题里的下划线、填空横线、选择题的选项线，在做识别和排版还原时需要去掉，但又不能伤到左右两边的文字。

这几类场景的共同特征是：线条是有方向的、相对连续的长条状结构；文字的笔画是相对短的、方向随机的结构。我们要利用的恰恰是这两者在形态学上的差异。

1.2 为什么选 C# + OpenCvSharp

说实话，做图像处理很多人第一反应是Python。但在我实际的项目环境里，核心业务系统是C#写的，整套Web API和数据库访问都是.NET体系，为了一个预处理功能单独开一个Python服务得不偿失。直接在一个C#服务里集成OpenCvSharp，进程内完成图像处理，部署运维都最简单。

OpenCvSharp本身是OpenCV的C#封装，API风格跟原版几乎一致，文档和示例虽然比Python版少，但核心功能一个不少。对我来说比较关键的是它支持NuGet安装，Visual Studio里两分钟就能跑起来，不折腾环境。

市面上也有AForge.NET这种老牌C#图像库，但说实话它的形态学操作、图像修复这类高级功能不够全，性能也一般。OpenCvSharp底层还是原生的OpenCV C++代码，处理大图的速度明显快很多。我们项目里一张A4扫描件大概2000x3000像素，用OpenCvSharp做形态学加修复，单张耗时在100到200毫秒之间，完全能满足业务要求。

1.3 技术方案的取舍：为什么走上“提取+修复”这条路

解决“去除文字中的线条”至少有四种常见思路，我逐一试过，最终才确定用形态学提取加图像修复的组合。

第一种思路是直接阈值过滤。如果线条和文字颜色差异比较大，尝试用颜色阈值把线条单独筛出来。但这要求线条颜色和文字颜色有足够大的区分度，实际扫描件里往往做不到，线条和文字经常是同一颜色的深浅不同，很多时候阈值一调，文字笔画直接没了。

第二种思路是霍夫变换检测直线。OpenCV的HoughLinesP确实能检测出图像里的直线段，但问题在于它检测的是“边缘”，扫描件噪点多的时候会检出一大堆假线段，而且无法准确界定线条的宽度范围，去掉线条时要么背景被掏空，要么残留碎片。

第三种思路是频率域滤波。把图像做傅里叶变换，线条方向上对应的高频分量去掉再做逆变换。理论很漂亮，实际效果受扫描件光照不均影响大，容易产生波纹伪影，代码复杂度也高，不适合快速落地。

第四种思路就是最终采用的：形态学操作提取线条结构，然后用图像修复（Inpaint）填补被擦除的位置。形态学开运算能够根据结构元素的形状和尺寸，精准地筛选出“长条状”的线条，同时让文字笔画因为尺寸不匹配而被腐蚀掉。提取出线条掩膜后，再用Telea算法或者Navier-Stokes算法从线条边界向内传播颜色信息，实现无损修补。这个方案兼顾了准确性和可控性，参数也比较直观，是我测试下来效果最稳定的。

2. 核心实现：形态学提取线条与图像修复

2.1 环境准备与NuGet包安装

第一步先建工程。用Visual Studio 2022创建一个.NET 6或.NET 8的控制台应用，然后通过NuGet安装OpenCvSharp4和OpenCvSharp4.runtime.win。

dotnet add package OpenCvSharp4 dotnet add package OpenCvSharp4.runtime.win

这里有一个容易踩的坑：OpenCvSharp4.runtime.win是Windows平台的运行库包，它会把OpenCV的原生DLL拷到输出目录。如果你的目标是Linux服务器（比如用Docker部署.NET服务），需要改成OpenCvSharp4.runtime.ubuntu或对应平台的runtime包。如果目标平台装了OpenCV的原生库，也可以不装runtime包，直接依赖系统级OpenCV，但依赖关系会复杂一些。

安装完成后，先在程序入口写一段最简单的代码验证环境：

Console.WriteLine(OpenCvSharp.Cv2.GetVersionString());

能输出OpenCV版本号，说明环境就绪了。我用的是OpenCvSharp 4.8.0，对应OpenCV 4.8.0。

2.2 图像预处理：灰度化与二值化

在提取线条之前，必须先把图像转成灰度图，再做二值化。原因很简单：形态学操作处理的是“前景”和“背景”的分布，彩色图会引入太多无关信息。灰度化之后，图像只有亮度维度，才能用阈值把文字和线条变成统一的前景像素。

读取图像的代码：

using OpenCvSharp; // 读取原图，保留彩色通道（后面修复时需要用到颜色信息） using var src = Cv2.ImRead("input.png", ImreadModes.Color); if (src.Empty()) { Console.WriteLine("图片读取失败，请检查路径"); return; } // 转为灰度图 using var gray = new Mat(); Cv2.CvtColor(src, gray, ColorConversionCodes.BGR2GRAY);

这里需要注意：读图时用ImreadModes.Color保留彩色，是因为修复操作需要从周围的彩色像素取样填充。如果读成灰度图，修复出来的区域只会是黑白渐变，对某些带颜色的线条场景效果差一些。

二值化的选择比较讲究。我一开始用的是固定阈值Cv2.Threshold(gray, binary, 180, 255, ThresholdTypes.Binary)，在实验室条件下效果还行，但换到真实的扫描件就出问题——光照不均、纸张泛黄导致背景亮度波动很大，180这个阈值对深色区域背景已经变成黑色了，前景和背景全乱套。

后来改用Otsu全局自适应阈值，效果好很多：

using var binary = new Mat(); Cv2.Threshold(gray, binary, 0, 255, ThresholdTypes.Binary | ThresholdTypes.Otsu);

Otsu算法会按照灰度直方图的分布自动找到一个分割阈值，把前景（文字、线条）和背景（纸张）分开。在背景整体偏亮、前景整体偏暗的扫描件场景里，效果相当可靠。

如果你处理的是拍照图片，光照特别不均匀，比如图片一侧亮一侧暗，Otsu也可能失效。这种情况建议用自适应阈值：

using var binary = new Mat(); Cv2.AdaptiveThreshold( gray, binary, 255, AdaptiveThresholdTypes.GaussianC, ThresholdTypes.Binary, blockSize: 51, c: 10 );

blockSize是局部窗口大小，建议取奇数，一般25到51之间；c是从局部均值或高斯加权均值中减去的常数，用于调节灵敏度。自适应阈值对光照变化不敏感，但会把背景的噪点放大，后面提取线条的难度会变大，所以能用Otsu的场合我会优先用Otsu。

还要注意一点：上面得到的二值图，前景（文字和线条）是白色，背景是黑色。如果原图是黑底白字，或者反色扫描，需要先做一次反色操作：

using var binaryInv = new Mat(); Cv2.BitwiseNot(binary, binaryInv);

2.3 构造结构元素，选定“线条”的形状

形态学操作的核心是结构元素（Kernel），它决定我们“关注”什么形态的特征。这一步要理解一个关键概念：结构元素就是一把尺子，尺子的形状决定你量什么形状的特征。

对于去除线条的需求，我们要构造两类结构元素：横向长条和纵向长条。

横向长条结构元素的大小是Size(width, 1)，比如宽度40、高度1：

var horizontalKernel = Cv2.GetStructuringElement( MorphShapes.Rect, new Size(40, 1) );

它的含义是：只保留图像中“在水平方向上连续延伸至少40像素”的结构。横线扫描件的线条通常有几百甚至上千像素长，所以40像素的宽度门槛可以把横线完整保留；而文字笔画横向连续长度一般只有几个像素到十几个像素，在开运算过程中会被当成“太短的结构”腐蚀掉。

纵向长条结构元素同理，高度远大于宽度：

var verticalKernel = Cv2.GetStructuringElement( MorphShapes.Rect, new Size(1, 40) );

这里Rect代表结构元素是矩形，当然也可以用MorphShapes.Ellipse椭圆形结构元素，边缘更平滑，但对细线条来说区别不大，矩形计算更快。

关于结构元素的尺寸，实际调参时要注意匹配线条在图像中的像素宽度和长度。我处理的票据扫描件里，横线一般在2到3像素宽，但横向延伸超过800像素。结构元素的高度设为1，正好贴合线条宽度；宽度设40，能过滤掉多数文字笔画。如果线条更粗，比如一些打印体的下划线达到5像素宽，高度就要调整为3到5，否则开运算会把线条截断，残留线条碎片。

2.4 用形态学开运算提取“纯线条”

这一步是整个方案的核心机制。开运算（MorphTypes.Open）的过程是：“先腐蚀，后膨胀”。腐蚀操作会让白色像素区域缩小一圈，膨胀操作让缩小后的区域再恢复一圈。

关键在于：线条很长，腐蚀完即使瘦了一圈，依然是连续的白色结构，膨胀之后基本能恢复原状；而文字笔画较短，腐蚀完之后可能完全消失，或者碎成几个孤立的小点，膨胀之后无法恢复成完整的笔画。

所以在开运算的输出里，剩下的基本都是线条结构，文字不见了。这一步的效果验证方式很简单：把结果保存成图片，肉眼看一看，如果只剩横线且没有文字笔画，就说明结构元素选对了。

代码实现：

using var horizontalLine = new Mat(); Cv2.MorphologyEx( binary, horizontalLine, MorphTypes.Open, horizontalKernel );

如果既要去横线又要去竖线，比如处理网格纸，需要分别做横向和纵向的开运算，然后把两张掩膜合并：

using var verticalLine = new Mat(); Cv2.MorphologyEx(binary, verticalLine, MorphTypes.Open, verticalKernel); using var lineMask = new Mat(); Cv2.BitwiseOr(horizontalLine, verticalLine, lineMask);

BitwiseOr是逐像素取或，把横向掩膜里的白色区域和纵向掩膜里的白色区域合并到一张图上。这张lineMask就是我们最终要交给修复算法的“破坏区域指示图”。

我踩过的一个坑：一开始我直接用Cv2.Add(horizontalLine, verticalLine, merged)来合并，结果横竖线交叉的地方灰度值变成255以上被截断，效果和BitwiseOr差不多；但如果线条掩膜是灰度图（比如形态学后的边缘有残留），Add会导致白色区域过曝。所以标准做法是用BitwiseOr。

2.5 图像修复：让线条“消失”且不伤文字

拿到线条掩膜之后，下一步就是把掩膜上的线条区域从原图上擦掉。最朴素的做法是直接把这些像素设为白色或者黑色。但如果直接填白色，文字和线条交叉的地方会出现“镂空”的白点，文字笔画中间断了一截，OCR照样识别不对。

这里的关键是使用图像修复（Inpaint）算法，让被擦除的区域利用周围像素信息自动推算填充内容，实现视觉上的“无缝修复”。

OpenCV提供了两种修复算法，OpenCvSharp里对应枚举InpaintMethod：

1. InpaintMethod.Telea，基于快速行进法（Fast Marching Method），从待修复区域的边界逐层向内部推进，对于细小划痕、文字线条类的缺失，速度很快，效果自然。
2. InpaintMethod.NS，基于Navier-Stokes方程，把流体力学的思想用到图像修补上，擅长修复边缘结构较强的缺损，但速度稍慢。

对于去除细线条这类场景，我通常优先用Telea。修复半径一般设为3到5像素。半径过小，修复区域覆盖不全线条边缘；半径过大，修复区域附近的文字也可能被“抹糊”，字体边缘变虚。

完整修复代码：

using var resultSrc = new Mat(); Cv2.Inpaint(src, lineMask, resultSrc, 3, InpaintMethod.Telea);

注意：src是我们最开始读入的彩色图，lineMask是形态学提取的线条掩膜，resultSrc是修复后的输出图。修复过程是在彩色图上进行的，这样修复区域会参考周围的颜色信息，而不是灰蒙蒙一片。

在实际项目中，这一步做完基本就达到“去掉线条、保留文字”的效果了。如果还想做后续的OCR识别，可以把修复结果再做一次灰度化和二值化，得到干净的文档图。不过OCR部分的操作这篇文章不展开，先把去线条这步做扎实。

2.6 完整代码串联

把上面的代码串起来，一个最小可用的去线条流程如下：

using OpenCvSharp; class LineRemover { public static Mat RemoveLines(string inputPath, int kernelWidth = 40) { // 1. 读图 using var src = Cv2.ImRead(inputPath, ImreadModes.Color); if (src.Empty()) throw new Exception("图片读取失败"); // 2. 灰度化 + Otsu二值化 using var gray = new Mat(); Cv2.CvtColor(src, gray, ColorConversionCodes.BGR2GRAY); using var binary = new Mat(); Cv2.Threshold(gray, binary, 0, 255, ThresholdTypes.Binary | ThresholdTypes.Otsu); // 3. 形态学提取横向线条 var horizontalKernel = Cv2.GetStructuringElement( MorphShapes.Rect, new Size(kernelWidth, 1) ); using var horizontalLine = new Mat(); Cv2.MorphologyEx(binary, horizontalLine, MorphTypes.Open, horizontalKernel); // 4. 形态学提取纵向线条（可选） var verticalKernel = Cv2.GetStructuringElement( MorphShapes.Rect, new Size(1, kernelWidth) ); using var verticalLine = new Mat(); Cv2.MorphologyEx(binary, verticalLine, MorphTypes.Open, verticalKernel); using var lineMask = new Mat(); Cv2.BitwiseOr(horizontalLine, verticalLine, lineMask); // 5. 修复 var result = new Mat(); Cv2.Inpaint(src, lineMask, result, 3, InpaintMethod.Telea); return result; } static void Main(string[] args) { using var result = RemoveLines("input.png", 40); Cv2.ImWrite("output.png", result); Console.WriteLine("处理完成"); } }

这套代码跑了真实测试：一张带横线的合同扫描件，原始OCR识别率67%，处理后识别率到了94%。核心的提升来自线条被清除后，文字笔画不再和线条黏连。

3. 参数调优与不同场景适配

3.1 结构元素尺寸怎么定

结构元素的尺寸是整套方案里最关键的超参数。太大会把笔画比较长的汉字（比如“一”“二”“量”这些横画多的字）误判成线条提取进去，修复后这些字会变形；太小则提取不完整，线条残留严重。

我建议先量一下目标图片里文字的实际像素尺寸，再决定结构元素长度。经验公式：结构元素宽度取文字平均宽度的1.5到2倍。比如一张300 DPI扫描的A4文档，一个正常大小的汉字大概是80x80像素，那么横向结构元素的宽度可以设成80到120，这样普通的文字笔画基本都能被腐蚀掉，而横线却有几百像素长，不受影响。

如果线条较短（比如表格里的短横线只有60像素），而文字又较大，参数就需要反复试。我的做法是写一个简单的控制台程序，把kernelWidth作为命令行参数传入，快速批量生成几张中间结果图，肉眼对比，找到最优值。这比在代码里瞎试高效得多。

3.2 修复半径的调节

Cv2.Inpaint的第三个参数是修复半径，它决定修复时取样的范围。半径太小，修复区域边缘会有残留的线条颜色；半径太大，修复过渡区域过宽，文字边缘会变模糊。

实际操作中，修复半径可以直接跟线条的宽度挂钩。线条越粗，半径越大。2到3像素宽的细线，半径设3就够了；5像素宽的粗线条，建议设为5。我一般不会超过5，因为超过5之后文字边缘的锐利度明显下降。

3.3 不同场景参数速查表

根据我测试过的几类典型场景，参数可以直接套用：

特别注意：合同下划线这种粗线场景，结构元素高度如果还是1，开运算会把宽度大于1的粗线条腐蚀成几段细线，最后修复不完整。这时候高度要调到3甚至5。

3.4 交叉线的断点问题

处理横竖交叉的网格线时，会出现一个奇怪的现象：线条在交叉处被修复后有一个小“疙瘩”或断点。原因是横线和竖线在交叉处是重叠的，形态学开运算之后，交叉点的灰度值和单线条处不同，修复算法在这个位置的推算会有偏差。

解决办法是在合并掩膜后，对lineMask做一次小的膨胀操作，把交叉处的掩膜区域连成一片：

using var kernel3 = Cv2.GetStructuringElement(MorphShapes.Rect, new Size(3, 3)); Cv2.Dilate(lineMask, lineMask, kernel3);

膨胀一圈后掩膜更完整，修复算法在处理交叉处时能获得更多邻域信息，效果自然更好。

4. 常见问题与排查技巧实录

4.1 文字跟着被“擦掉”了

这是最容易遇到的问题。最直接的原因是结构元素的尺寸设置不当，导致文字笔画被误判为线条。另一个隐蔽原因是图像分辨率太大，扫描件如果是600 DPI，文字笔画尺寸比300 DPI翻了一倍，原来合适的kernelWidth现在把文字笔画也留下来了。

排查方法：把horizontalLine/verticalLine这两张掩膜保存成图片，看一眼提取的线条里面有没有文字轮廓。如果掩膜里有文字，说明结构元素的长度或高度不合适，调大宽度、调整高度直到掩膜里只有线条。

另外一个技巧：如果文字笔画确实和线条一样长，可以改用“线条长度+线条宽度”联合判定的方式，利用OpenCV的轮廓分析进一步过滤。先对掩膜做连通域分析，然后按照轮廓的“外接矩形长宽比”和面积过滤掉那些像文字碎片的非线条轮廓。这在处理复杂背景时很有用。

4.2 线条去除后留下灰印

修复后的图像上，原来线条的位置有一片淡淡的灰色残留，肉眼看不太清楚，但二值化之后又隐约能看到一条线。这通常是因为修复半径太小，修复算法没有完全覆盖线条边缘的过渡带。

解决办法是把修复半径从3调到5，或者把掩膜做一次轻度膨胀后再传给Inpaint。如果还是不行，可能是原图本身压缩率太高，线条边缘有严重的马赛克伪影，建议先用高斯模糊做一次轻降噪再走整套流程。

4.3 彩色水印线条怎么处理

有些证件或票据的底纹是彩色的，灰度化之后彩色线条和文字的灰度值可能非常接近，形态学方法容易把文字一起带走。

这种情况我的做法是把图像从BGR转到HSV色彩空间，用色调（Hue）通道作为形态学处理的输入。因为彩色底纹的色相往往和文字的色相差异较大，比如蓝色底纹对应的Hue值在100到130之间，纯黑文字在无色彩区域，这样可以用Cv2.InRange把彩色线条单独筛选出来，生成掩膜后再走修复流程。

using var hsv = new Mat(); Cv2.CvtColor(src, hsv, ColorConversionCodes.BGR2HSV); using var mask = new Mat(); Cv2.InRange(hsv, new Scalar(100, 50, 50), new Scalar(130, 255, 255), mask);

InRange可以提取指定颜色范围的像素，蓝色底纹在这个范围内会被标白，文字因为不满足阈值范围保持黑色。之后再用这个mask做形态学清洗即可。这个方法对纯色水印效果很好，但对渐变色底纹仍然困难。

4.4 Inpaint后文字边缘模糊

修复算法毕竟是根据周边像素猜测填充内容，如果待修复区域紧贴文字笔画，修复后的文字边缘多少会有点虚。这一点在OCR识别时影响不大，但如果做的是面向人眼的文档还原，就需要尽量减少对文字边缘的影响。

我的经验：第一，掩膜要尽量“细”，不要过度膨胀；第二，修复半径在保证覆盖线条的前提下取最小值；第三，如果目标是OCR，最后可以加一步锐化或二值化，强制把模糊的边缘吃回清晰状态。

using var sharp = new Mat(); Cv2.GaussianBlur(result, sharp, new Size(0, 0), 1.0); Cv2.AddWeighted(result, 1.5, sharp, -0.5, 0, sharp);

这种“Unsharp Mask”式的锐化操作能让修复区域的边界看起来更清晰，对后续识别有正面帮助。

4.5 性能优化与内存管理

处理高分辨率扫描件时，OpenCvSharp会占用不少内存，尤其是Mat对象用完后如果不释放，程序跑一段时间内存就飙上去了。C#的垃圾回收虽然能回收托管内存，但Mat对象持有的是非托管内存，依赖Dispose主动释放。

最佳实践是给所有Mat对象套上using，让它们作用域结束时就释放。我上面所有代码都遵循了这个模式。如果图像数量大、并发高，考虑用Cv2.Cuda相关的GPU加速版本。OpenCvSharp支持OpenCV的CUDA模块，但需要额外安装对应runtime包，并且要求机器有NVIDIA显卡。如果只是批处理离线任务，CPU版本速度通常也能接受。

还有一个小经验：Cv2.ImRead和Cv2.ImWrite在Windows下中文路径有时会出问题。OpenCV底层用的是C接口，对系统的字符编码支持不太稳定。处理中文文件名时，建议先用File.ReadAllBytes读成字节数组，再通过Cv2.ImDecode解码，写文件时用Cv2.ImEncode编码后写盘。这个方法能绕开大部分中文路径的坑。

var bytes = System.IO.File.ReadAllBytes("带中文路径的图片.png"); using var src = Cv2.ImDecode(bytes, ImreadModes.Color); // 处理... Cv2.ImEncode(".png", result, out var outBytes); System.IO.File.WriteAllBytes("输出.png", outBytes);

4.6 一个偷懒技巧：把参数做成配置项

这个项目在业务系统中要处理不同类型的图片，参数不能写死。我把kernelWidth、kernelHeight、inpaintRadius、是否启用竖直方向、是否先做自适应阈值这些都做成了JSON配置项。每个业务场景对应一套配置，切换场景时自动加载。

这样做的好处是现场服务遇到新的图片格式时，不用改代码重新发布，后端改一下配置就能适配。上个月遇到一种新的单据，线条是虚线，我用默认配置提取不完整，后来把kernelWidth调小到20、加了一次闭运算，问题就解决了。整个过程只改了配置，没有动一行代码。

5. 写在最后的一点心得

这套方案上线跑了几个月，处理了几万张图片，整体效果稳定。我个人最深的体会是：形态学操作的门槛不高，但真正决定效果的是你是否理解“结构元素到底在量什么”。每次遇到新类型的图片，我都会先花几分钟看看原图和线条掩膜，再决定参数方向，这比盲目换算法靠谱得多。

如果后续你想进一步优化，可以朝两个方向扩展：一是加入文字检测模型，检测到文字区域后只对非文字区域做掩膜提取，从源头避免误伤；二是把线条提取的结果接入深度学习分割模型，用分割网络直接输出线条掩膜。不过这些都是加分项，对于绝大多数业务场景，纯OpenCV的形态学方案已经够用且可控。希望这篇文章能帮你少踩几个坑。

本文还有配套的精品资源，点击获取