简介C#与HALCON联合开发的完整机器视觉检测系统源代码包面向机器视觉工程师、工业自动化软件开发者和相关专业学生适用于工件表面质量检测项目的开发与二次改造。包体共245个文件大小约45.48MB以80个C#源文件、29个动态链接库、23个调试文件以及配置文件、数据库脚本和示例图像等构成覆盖图像采集、预处理、特征提取、结果反馈等完整模块代码目录与工程结构便于按功能拆分学习。目前已有7064人浏览学习说明其在视觉开发社区中具备一定参考价值。借助源码内容读者可以理解C#调用HALCON的接口写法、视觉流程的状态组织以及界面与算法模块的衔接方式压缩包内附带的BMP样例图像和数据库/CSV文件也有助于直接运行和验证检测逻辑。1. 一套能落地的视觉检测系统源码到底该长什么样拿到一套号称“完整”的视觉检测系统源码最怕的不是代码看不懂而是拆开发现只有算法demo、没有UI或者界面和采集是两张皮跑起来之后根本没法进产线。这套C# HALCON的视觉检测软件系统是我最近拆过比较“像样”的一套从相机采集、图像预处理、定位检测、结果判定到数据库存储、外部通讯全都有不是单点算法演示而是按“一台上位机软件”的标准做的。适合两类人一是要做毕业设计或公司内部视觉项目需要一套能改能跑的骨架二是已经在用HALCON做算法但对C#工程化封装不熟想看看UI线程、采集线程、算法线程怎么组织的开发者。先给结论这套系统的价值不在某一个检测算法多高级而在于它把HALCON的算子能力和C#的界面工程完整缝合在了一起——这一点恰恰是很多视觉工程师自己从零搭时最耗费时间的部分。对应关键词“C# halcon 机器视觉软件系统 视觉检测完整系统”这篇文章会从技术栈、目录结构、核心模块、运行配置到二次开发一条线拆完。2. 技术栈与工程结构HALCON和C#是怎么“缝”在一起的2.1 技术选型为什么是C# HALCON而不是C或Python视觉检测系统的上位机选型业内基本就三条路C Halcon/C接口、C# Halcon/.NET接口、Python Halcon/Python接口。C性能上限最高但开发效率尤其是界面开发效率很低Python上手快但部署麻烦而且和HALCON的交互性能损耗在工业现场有时不可接受。这套源码选的是C# HALCON的组合对应HALCON的.NET接口通过HalconDotNet命名空间把HALCON的算子封装成C#可以直接调用的类和方法。从工程角度看C#做上位机有几个实打实的优势WinForm/WPF的控件生态成熟HWindowControl可以直接嵌进窗体显示图像多线程写起来比C顺手采集线程、算法线程、UI线程分离的成本低数据库和通讯库齐全对接MES、SQLite都很快。代价是性能峰值不如C但视觉检测这类应用瓶颈通常在相机采集和算法耗时C#的托管层开销在毫秒级对绝大多数产线节拍没有影响。这套源码的定位是“完整系统”所以它不是把HALCON算子包一层就完事而是按真实项目分了UI层、业务层、算法层、硬件抽象层。UI层负责显示和交互业务层管检测流程和状态机算法层封装HALCON算子硬件抽象层管相机和IO。各层之间通过接口或事件解耦这是它值得参考的核心设计。2.2 目录结构拆解从MainForm到AlgorithmEngine解压源码包后先别急着编译把目录结构过一遍。整套解决方案包含一个主工程和若干个辅助工程核心目录大概是这样的VisionDetectSystem/ ├── MainForm.cs // 主界面TabControl承载各功能页 ├── MainForm.Designer.cs ├── Camera/ │ ├── CameraAdapter.cs // 相机抽象基类 │ ├── GigECamera.cs // GigE接口相机实现 │ └── CameraManager.cs // 相机管理单例负责枚举、打开、采集 ├── Halcon/ │ ├── HalconHelper.cs // 图像格式转换、HObject与Bitmap互转 │ ├── AlgorithmEngine.cs // 算法引擎加载hdvp或调用导出算子 │ └── ResultRenderer.cs // 在HWindowControl上绘制ROI、结果 ├── UI/ │ ├── CameraPage.cs // 采集页面 │ ├── DetectPage.cs // 检测参数页面 │ ├── ResultPage.cs // 历史结果页面 │ └── Controls/ │ ├── DoubleBufferPanel.cs │ └── NumericBox.cs ├── Database/ │ ├── SQLiteHelper.cs // 基于System.Data.SQLite的封装 │ └── DetectRecord.cs // 检测记录实体 ├── Communication/ │ ├── ModbusTcpServer.cs // 结果输出用的Modbus TCP服务端 │ └── IOController.cs // 简易IO控制 ├── Common/ │ ├── AppConfig.cs // 配置文件读写 │ └── LogHelper.cs // 日志 └── Resources/ ├── 相机参数.xml └── 检测配方.json几个关键点说一下CameraManager是单例因为一台工控机可能接多个相机但相机资源全局只能有一份管理避免了多个窗体各自打开相机导致设备占用冲突。AlgorithmEngine是算法入口它不直接散落调用HALCON算子而是把检测流程抽象成“加载图片→预处理→定位→检测→输出结果”的管道换算法时只改这个类。UI和算法完全分离CameraPage只负责触发采集和显示拿到图像后通过事件交给AlgorithmEngine算完再通过回调把结果送回UI。这个设计避免了把HALCON的HObject直接塞进UI线程导致句柄冲突。2.3 图像数据流从相机帧到HObject再到BitmapHALCON图像和C#的Bitmap是两种完全不同的内存结构很多新手第一次在这卡住。HALCON的HObject内部是宽字符指针指向的通道数据而C#控件显示要么用HImage、HWindowControl直接显示要么转成Bitmap给PictureBox用。这套源码提供的转换思路是// HalconHelper.cs 关键代码 public static Bitmap HObjectToBitmap(HObject image) { HTuple width, height; HOperatorSet.GetImageSize(image, out width, out height); // 转换颜色空间HALCON默认为RGB顺序 HObject imageRGB; if (HOperatorSet.CountChannels(image) 1) { HOperatorSet.Compose3(image, image, image, out imageRGB); } else { imageRGB image; } // 获取指针并拷贝到Bitmap IntPtr pointer; HTuple type; HOperatorSet.GetImagePointer1(imageRGB, out pointer, out type, out width, out height); Bitmap bitmap new Bitmap(width, height, PixelFormat.Format24bppRgb); Rectangle rect new Rectangle(0, 0, width, height); BitmapData bitmapData bitmap.LockBits(rect, ImageLockMode.WriteOnly, PixelFormat.Format24bppRgb); // 注意HALCON的通道顺序是RGBBitmap在内存中是BGR需要逐行处理 unsafe { byte* src (byte*)pointer; byte* dst (byte*)bitmapData.Scan0; int stride bitmapData.Stride; for (int y 0; y height; y) { for (int x 0; x width; x) { int srcIndex y * width * 3 x * 3; int dstIndex y * stride x * 3; dst[dstIndex] src[srcIndex 2]; // B dst[dstIndex 1] src[srcIndex 1]; // G dst[dstIndex 2] src[srcIndex]; // R } } } bitmap.UnlockBits(bitmapData); return bitmap; }这段代码里最值得注意的就是RGB和BGR的顺序互换直接用Marshal.Copy整体拷贝不做通道处理的话显示的图像颜色是反的检测效果就像“色偏”找边缘、找缺陷的思路全会被带偏。如果只做灰度检测可以在HALCON端先Rgb1ToGray转成单通道再直接按8位灰度拷贝性能会快不少。3. 核心模块拆解一个检测请求从进入到返回的完整链路3.1 采集模块多相机管理和采集回调的线程模型先看相机这一层。CameraManager维护了一个Dictionarystring, CameraAdapter键是相机编号值是相机实例。打开相机时按配置里的相机IP和厂商SDK类型创建对应实例。这里用了一个抽象基类public abstract class CameraAdapter { public string CameraID { get; set; } public bool IsOpened { get; protected set; } public abstract bool Open(); public abstract void Close(); public abstract bool TriggerOnce(out HObject image); public abstract void StartGrab(); public abstract void StopGrab(); public event ActionHObject ImageGrabbed; }采集线程和算法线程是分离的。StartGrab()启动一个后台线程循环调用SDK的采集接口取帧拿到HObject后触发ImageGrabbed事件。这套源码的做法是采集线程只负责取帧图像直接扔给ImageGrabbed由订阅方检测流程决定是立即处理还是放入队列。这样的好处是采集不会因为算法耗时丢帧。坏处是如果检测速度跟不上采集速度事件积压会导致内存增长所以实际用的时候通常会在ImageGrabbed里做“当前帧正在处理则丢弃新帧”的防重入判断。常见的工业相机SDK采集回调本身就是在一个独立线程里而HALCON的HObject并不是线程安全的同一个HObject不能在两个线程同时操作。这套源码的做法是每帧图像在回调里立即通过HOperatorSet.Clone克隆一份再发出去避免事件接收方处理期间图像内存被采集线程释放。3.2 检测引擎HDevEngine动态加载与导出算子的封装方式HALCON给C#用的方式有两种一是通过HDevEngine动态执行.hdvp或.hdev脚本二是把HDevelop里的算子导出成C#代码直接编译进工程。这套源码两种都支持重点是AlgorithmEngine这个封装类public class AlgorithmEngine { private HDevEngine _engine; private HDevProcedure _procedure; private string _procedureName; public AlgorithmEngine(string hdvpPath) { _engine new HDevEngine(); _engine.SetProcedurePath(Path.GetDirectoryName(hdvpPath)); _procedure new HDevProcedure(Path.GetFileName(hdvpPath)); _procedureName Path.GetFileNameWithoutExtension(hdvpPath); } public DetectResult Run(HObject inputImage, DetectParam param) { HDevProcedureCall call _procedure.CreateCall(); call.SetInputIconicParamObject(InputImage, inputImage); call.SetInputCtrlParamTuple(MinThreshold, param.MinThreshold); call.SetInputCtrlParamTuple(MaxThreshold, param.MaxThreshold); call.SetInputCtrlParamTuple(MinArea, param.MinArea); call.Execute(); // 获取结果 HObject resultRegion call.GetOutputIconicParamObject(ResultRegion); HTuple defectsCount call.GetOutputCtrlParamTuple(DefectsCount); return new DetectResult { DefectsRegion resultRegion, DefectsCount defectsCount }; } }HDevEngine的好处是算法调整不需要重新编译C#直接改HDevelop脚本保存后重启软件就生效。这对现场调试来说是“后悔药”——产线上算法参数要微调改完脚本重跑一次就行不用跟C#工程编译较劲。那这种方式的代价是什么一是性能比编译进工程的导出算子略差因为每次调用都要做参数解析、脚本上下文切换二是HDevEngine底层依赖HALCON的运行时目标机器上必须装对应的运行时且版本一致。如果节拍要求高建议把稳定后的脚本导出为C#算子替换AlgorithmEngine内部实现接口不变上层不用动。3.3 显示与交互HWindowControl上的ROI绘制与结果叠加这套系统的检测结果显示不是简单在HWindowControl上显示原图而是把检测区域、缺陷位置、NG/OK标签都画在图像上。这部分对应ResultRenderer类核心是用HALCON的disp_*系列算子public void RenderResult(HWindowControl hWindow, HObject image, ListRegionInfo regions) { hWindow.HalconWindow.DispObj(image); hWindow.HalconWindow.SetColor(green); hWindow.HalconWindow.SetLineWidth(2); foreach (var region in regions) { if (region.Type RegionType.ROI) { hWindow.HalconWindow.SetDraw(margin); hWindow.HalconWindow.DispRectangle(region.Row, region.Column, 0, region.Width, region.Height); } else if (region.Type RegionType.Defect) { hWindow.HalconWindow.SetColor(red); hWindow.HalconWindow.DispRegion(region.HObject); } } // 输出文字结果 hWindow.HalconWindow.SetTposition(10, 10); hWindow.HalconWindow.WriteString($Result: {regions.Count} defects); }这里的显示根目录是HWindowControl它内部封装了HALCON的HWindow句柄。新手容易犯的错是把HWindowControl放在TabControl的多个页签里切换页签后HWindowControl的句柄会失效。解决这类问题最稳妥的做法是在OnVisibleChanged里重新关联句柄具体写法也就是先判断hWindow.Handle是否有效无效就重新初始化显示上下文。3.4 数据闭环SQLite记录检测结果与追溯查询检测完的数据如果没有落到库里等于白检测。这套源码用了SQLite做本地存储理由很简单单机部署免安装、一个文件搞定、支持SQL查询。检测记录的实体结构涵盖基本的追溯字段、图片路径、检测结果、时间戳。CREATE TABLE IF NOT EXISTS detect_record ( id INTEGER PRIMARY KEY AUTOINCREMENT, product_code TEXT NOT NULL, batch_id TEXT, result INTEGER NOT NULL DEFAULT 0, defect_count INTEGER DEFAULT 0, image_path TEXT, operator TEXT, create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP );业务逻辑上每检测完一个产品写入一条记录同时把NG图片复制到专门的“NG文件夹”。查询历史记录时按时间范围或批次号筛配合ResultPage里的DataGridView展示双击某行可以在图像显示区重新打开当时的检测图片。这也就是完整系统比demo多的部分算法是核心但追溯、报表、日志这些“周边”才决定了软件能不能真正在产线上用起来。数据库模块用了参数化查询防止注入这里不再展开数据访问代码大致实现就是标准的SQLiteCommand加Parameter。4. 运行配置与参数体系从光路到软件设置的一次完整梳理4.1 环境依赖清单HALCON版本、.NET框架与相机SDK把源码编译通过之前先把依赖项理清楚。这套系统是针对HALCON 17及以上版本开发的底层通过HalconDotNet程序集引用C#工程是.NET Framework 4.6.1或4.7.2具体看你本机装的Visual Studio版本。编译时如果报找不到HalconDotNet需要手动添加引用路径在HALCON安装目录下的bin\dotnet文件夹里。相机SDK这块源码里默认封装的是GigE Vision协议相机的通用取流实现。GigE Vision相机一般分为带SDK和走DirectShow两种方式。这套源码用的是厂商SDK方式所以要装对应相机品牌的SDK运行时。如果你手头没有该品牌相机想先跑通流程可以在CameraAdapter里加一个“模拟相机”实现——但这是后面改源码的内容了现在先说清楚一件事这套系统的源码默认不包含相机模拟器跑完整采集链路需要接入真实相机或对采集层做改造。4.2 全局配置检测配方JSON与相机参数XML的作用边界配置方面源码把参数分成了两类理解这个划分对改参数很重要相机参数.xml存储相机IP、曝光时间、增益、触发模式等硬件相关参数由CameraManager在启动时读取并应用到相机。检测配方.json存储检测算法的阈值、面积范围、ROI坐标等工艺参数由AlgorithmEngine在处理每张图前加载。配方这个概念是从产线实际需求来的换产品型号换一套检测参数不需要改程序只需要切换配方文件。{ recipeName: connector_1, minThreshold: 128, maxThreshold: 200, minArea: 50, maxArea: 5000, roi: { row: 300, column: 400, width: 200, height: 150 } }读配置的代码是标准JSON序列化/反序列化没有用第三方重量级框架写出效果大致如下public static DetectParam LoadRecipe(string filePath) { string json File.ReadAllText(filePath); return JsonConvert.DeserializeObjectDetectParam(json); }保存配方时顺手做一次参数合法性校验——比如minArea不能大于maxAreaROI坐标不能超出图像尺寸。很多线上检测异常都是参数越界引起的比如ROI画到了图像外面算法层面直接报错软件就“白屏”了。这套源码里在DetectPage保存时做了范围校验印象里还带了一个“临时生效”按钮用于不保存直接拿当前UI参数跑一张图验证效果这对现场调试是很贴心的功能设计。4.3 编译顺序与常见报错处理拿到源码后推荐按这个顺序编译和排查# 1. 先还原NuGet包 nuget restore VisionDetectSystem.sln # 2. 确认HalconDotNet引用路径 # 打开视觉工程检查引用中HalconDotNet的路径是否指向本机HALCON安装目录 # 3. 设置启动项目 # 右键解决方案 - 设置启动项目 - 选择主程序 # 4. 编译确认平台目标为x64 # 视觉软件几乎全部需要x64HALCON和相机SDK的64位版本才能配合编译报错大部分集中在两类。一类是HalconDotNet版本不匹配本机装的是HALCON 13源码引用的是17的程序集接口签名不同就会报方法不存在。解决方法是升级HALCON版本或者用本机HALCON导出的HalconDotNet.dll替换引用——一般推荐前者因为源码里用到的算子比较基础17往上的版本兼容性更好。另一类是相机SDK的dll没放到输出目录运行时在CameraManager.Open()里报DllNotFoundException把相机SDK的bin目录加到系统PATH或直接把dll拷贝到exe同级目录即可。4.4 跑通一个检测流程的最小步骤配置环境后第一次跑通不要急着接相机。把软件打开切到“检测参数”页面选择一张测试图片手动触发一次检测。这个流程不需要相机在线可以验证HALCON算法链路和UI展示是否正常。步骤如下打开软件确认主界面正常加载HWindowControl区域没有异常弹出。切到“检测参数”页点“加载图片”选择Resources目录下的测试图。保持默认配方参数点“执行检测”观察图像区是否画出ROI和缺陷Region。如果结果数显示正常再切到“历史记录”页确认刚才的检测结果写入了SQLite库。以上都通过后再接相机只验证采集和实时检测链路。这里有一个适用大多数项目的建议算法跑通之前永远不要先调相机。先拿到确定性的图片和确定性的算法结果再引入硬件的不确定性这样排查问题时才不会混淆是相机问题还是算法问题。5. 避坑与排查视觉检测系统落地中的5个高频问题5.1 采集图像颜色异常偏红或偏绿边缘检测结果明显不对现象是相机采回来的图在软件里显示红色和蓝色对调整个画面像开了滤镜检测阈值怎么调都达不到预期。原因是HALCON的HObject内存在通道顺序为RGB而System.Drawing.Bitmap在Format24bppRgb下的内存布局实际是BGR。直接按像素块拷贝不做通道重排就会出现颜色互换。另外如果是通过HOperatorSet.GetImagePointer1取指针要注意它针对的是单通道图像多通道要用GetImagePointer3。解决方法是写通道转换的扩展方法在图像首次进入UI前统一完成RGB到BGR的转换不要在每个显示逻辑里各转一次。5.2 切换Tab页后HWindowControl显示黑屏或报句柄无效现象是软件刚启动正常切到其他页再切回来图像显示区变黑或者直接抛异常“HWindow handle is invalid”。原因是HWindowControl在TabControl页签切换时控件的Handle会被重建HALCON的窗口句柄随之失效。源码里的ResultRenderer依赖hWindow.HalconWindow一旦句柄变了就会踩空。解决办法是在VisibleChanged事件里重新初始化显示private void hWindowControl_VisibleChanged(object sender, EventArgs e) { if (hWindowControl.Visible hWindowControl.Handle ! IntPtr.Zero) { HOperatorSet.SetWindowExtents(hWindowControl.HalconWindow, 0, 0, hWindowControl.Width, hWindowControl.Height); hWindowControl.HalconWindow.Clear(); } }如果你在把HWindowControl嵌进UserControl自定义控件也要在OnLoad里做同样的处理否则自定义控件复用时会复现同样的黑屏。5.3 实时检测时软件卡顿或内存持续上涨现象是相机触发连续检测跑一两个小时内存占用从200M一路涨到1G最后程序无响应或OOM。原因是检测流程中创建了太多HObject没有释放。HObject实现了IDisposable但很多开发者在事件回调里直接使用而不dispose。HALCON的内存管理在托管接口里并不完全自动HObject底层的native内存要手动释放。源码采用的做法是在ImageGrabbed事件处理完图像后统一调用Dispose()同时用GC.AddMemoryPressure辅助托管侧感知native内存占用。另外采集回调事件里如果检测速度跟不上图像帧会在队列里积压积压的都是大对象内存涨得更快。处理方式是在事件入口判断上一次检测是否仍在进行是则跳过当前帧private bool _isProcessing false; private void OnImageGrabbed(HObject image) { if (_isProcessing) return; _isProcessing true; try { var result _engine.Run(image, _currentParam); // UI上报 } finally { image.Dispose(); _isProcessing false; } }5.4 算法脚本换了但软件检测结果不变现象是在HDevelop里改完了检测参数保存hdvp脚本回到软件再跑检测结果和改之前一模一样。原因是AlgorithmEngine在初始化时加载了HDevProcedure而HDevEngine默认对脚本有缓存不重启进程不会重新加载外部变更。这不是bug是引擎设计的缓存机制。解决方法是写一个ReloadProcedure方法在检测页面加一个“重载脚本”按钮或检测前校验脚本文件的LastWriteTime有变化才重新创建HDevProcedure。这套源码里是按钮手动触发现场调试时这个习惯很重要。5.5 产线上偶发NG判错但同一张图离线重测又是OK现象是产线上同一产品连续过几次偶尔判NG把当时保存的图片拿出来离线跑又是OK导致追溯困难。原因多半是“复测的图和现场不是同一张”。有些系统保存图片时保存的是压缩后的JPEGJPEG有损压缩对边缘检测类项目影响很大可能直接把边缘像素压糊了。解决办法是要保存原始图或无损PNG用于复测源码里默认NG图片保存PNG格式就是为了保证复测图像和现场一致。另外还要确认存储时是否把所有预处理步骤也原样复现了比如是否做了灰度化、是否用了同一ROI坐标这些小差异在临界样本上很容易变成误判。6. 二次开发把自带示例算法换成你自己的检测流程6.1 算法替换最小改动原则下的接口适配拿到这套源码最常做的改动就是把默认的示例检测算法看起来是一个阈值分割找缺陷的流程换成自己项目需要的算法比如Blob分析、模板匹配、尺寸测量。推荐的做法是不要动AlgorithmEngine的调用方式只替换内部Run方法的实现。旧代码大致是这样的模式// 旧算法逻辑阈值分割找缺陷 HOperatorSet.Threshold(inputImage, out region, param.MinThreshold, param.MaxThreshold); HOperatorSet.Connection(region, out connectedRegions); HOperatorSet.SelectShape(connectedRegions, out selectedRegions, area, and, param.MinArea, param.MaxArea); HOperatorSet.CountObj(selectedRegions, out count);换成模板匹配时在Run里改成HOperatorSet.FindShapeModel即可。如果HALCON版本支持深度学习方法也可以在这里换ReadDlModel和ApplyDlModel但注意引用和运行时依赖要配套。6.2 定位逻辑前置让检测Region跟随产品位置产线上的产品位置不会每次都停在同一个像素坐标。这套源码里ROI是固定坐标的这在实际项目中不够用。改造方案是在检测前先做一次定位// 用形状匹配定位产品中心 HOperatorSet.FindShapeModel(inputImage, modelID, 0, 0.785, 0.5, 1, 0.5, least_squares, out row, out col, out angle, out score); // 根据定位结果平移ROI HOperatorSet.HomMat2dIdentity(out homMat2D); HOperatorSet.HomMat2dTranslate(homMat2D, row, col, out homMat2D); HOperatorSet.AffineTransRegion(roiRegion, out movedRoi, homMat2D, nearest_neighbor);定位逻辑是所有视觉检测系统的基础能力做不好产品一歪后面所有检测都是空谈。源码没有把这部分写全但对有经验的人来说是一个明确的改造点在DetectParam里加一个“是否启用定位”的开关启用时先匹配再检测不启用时走固定ROI。6.3 增加相机数量第二个相机怎么接入多相机扩展是产线常提的需求。CameraManager已经提供了按ID管理多相机的结构新增相机要做的事是在配置XML里加一段相机参数在UI的采集页面加一个相机切换下拉框在检测流程里根据当前选中的相机ID从CameraManager取出对应实例。额外要注意的是多个相机同时采集时的帧率控制和资源竞争CameraManager里可以加一个ListCameraAdapter统一管理采集时各相机独立线程运行检测引擎同一时间只处理一个相机的帧避免HDevEngine的并发调用冲突。6.4 验证方法改完之后的回归测试流程改完代码不要直接上产线。一个相对可靠的验证流程是接上相机拍50个已知OK和50个已知NG的样品记录软件给出的判定结果计算过杀率和漏杀率。过杀率是你把OK品判成了NG漏杀率是你把NG品放过了。视觉项目里这两个指标互相制约阈值调高漏杀降低但过杀升高调低则反过来。这套源码里NG图片保存和高亮显示功能对复测很有价值。拿到一批误判图统一重跑看算法输出的中间Steps是否在预期范围内。这比现场盯半天机器猜问题高效得多。从那以后我每改一次检测参数都强制走一遍“50/50回归”再允许切换配方这个习惯帮我挡掉了至少三次现场批量误判。希望帮到你。本文还有配套的精品资源点击获取