企业官网建设流程全解析

做工业摄像仪机芯（也就是相机模组）的上位机软件，技术选型这一关如果没走对，后面从界面开发到产线调试，每一步都可能被按在地上摩擦。我在这个领域踩了几年坑，前后用五套方案写过不用项目的机芯调试工具、产线视觉检测程序和批量配置工具，今天把这些经验一次性倒出来。这篇内容既适合刚接手机芯SDK、准备写第一个上位机小工具的人参考，也适合已经在产线上被界面卡顿、相机掉线、参数批量配置折腾到头疼的开发者。

先说结论：五套主流方案里，Windows产线场景下，C# WPF是最优解，没有之一。但“最优”不是凭空来的，它建立在需求匹配、团队技能栈、SDK对接难度、部署维护成本四个维度的综合权衡上。下面我会把五套方案的优缺点、为什么WPF最合适、以及产线适配阶段容易踩的坑全部摊开讲。

1. 为什么这个选型如此关键：先搞清楚上位机软件的真实需求

选型这件事，不能一上来就比语法、比框架、比生态，得先把自己要解决的问题定义清楚。机芯上位机软件在产线环境里的角色，和普通办公软件完全不一样，它要面对的是连续运行、异常环境、操作员低熟练度和快速换产这些实际场景。

1.1 机芯上位机软件的需求画像：不止是“能出图”

摄像仪机芯的上位机软件，通常是给工业相机模组配套的PC端工具，核心功能不外乎图像采集预览、参数设置、触发控制、数据保存，很多项目还要做简单的测量或状态监控。但真到了产线上，需求会复杂得多。

我做过的一个典型项目是产线用的机芯标定和测试程序，除了实时预览相机画面之外，还需要让操作工修改曝光、增益、白平衡、分辨率这类参数，并且要在几十台相机之间快速切换、把一份调好的参数一次性下发到所有设备上。软件还要记录每台机芯的测试结果，方便后续追溯。这种场景里，软件的稳定性和交互效率决定了整条产线的节拍。

所以，需求画像是这样的：

• 实时性要求高：相机的图像数据流是持续的，软件必须能在不丢帧的情况下完成预览和处理。
• 交互要求强：操作员不是开发者，界面必须直观到“零培训”也能上手。
• 设备种类多：同一个软件可能要对接不同型号、不同厂商的机芯SDK。
• 环境条件差：产线上可能有工控机、老旧Windows系统、触摸屏、小分辨率显示器。
• 部署要求快：换产线、加机位的时候，软件要能快速安装、批量配置。

这几点，直接决定了你选用什么技术路线，而不是反过来。

1.2 选型之前先想清楚的三件“决定性小事”

很多人在选型阶段纠结“QT好还是C#好”“Web技术能不能上”，但真正决定成败的往往是几件不起眼的小事。

第一，机芯厂商的SDK提供的是什么形态的接口。目前绝大多数工业相机模组厂商提供的SDK是C/C++动态库，比如MVS、Halcon、Basler的pylon、大恒的SDK等等。如果你的技术栈不能方便地调用C接口的DLL，那后续的对接成本会直线上升。

第二，部署环境长什么样。产线上的工控机普遍是Windows 7/10，甚至有一些还是32位系统。如果你的方案对运行库版本挑三拣四，现场光装环境都能折腾掉半天。

第三，团队自己擅长什么。如果你是一个人维护这个工具，没有前端工程师、没有专门的UI设计师，那么一个能自己搞定界面又能方便调用相机SDK的方案，远比一个花哨但要求全栈能力的方案合适。

把这三点想清楚，再去做横向对比，结论就会自然浮出来。

2. 五套主流方案横向测评：各打八十大板，看谁最合适

这里我按自己实际用过的顺序，把五套方案挨个过一遍。为了公平对比，我从开发效率、界面表现力、性能、SDK对接、部署维护这五个维度打分，满分5分。

2.1 方案一：Qt/C++——老牌豪强，性能和代价一样高

Qt/C++是很多老工程师的第一选择，尤其是做过嵌入式或者工控多年的团队，对C++有天然信任感。

优点是真不少：跨平台、渲染性能出色、信号槽机制写起来顺手、官方控件丰富。工业领域很多成熟的视觉软件就是基于Qt做的，比如Halcon自带的HDevelop界面风格。

但放到产线机芯上位机这个场景里，问题也很明显。首先是开发效率低，同样的界面，WPF可能两小时做完，Qt/C++可能要两天，因为每写一个界面都要手工调整布局和样式。其次是人才和生态问题，年轻开发者的C++功底普遍不如以前，招人困难，而且Qt在不同版本之间的API变动不小事，遇到问题在网上能找到的参考资料也不像C#那么集中。

我自己的体会是：如果你要写的是一个底层图像处理算法库，C++无可替代；但如果只是做一个机芯参数的调试工具、产线测试软件，用C++去堆业务代码，性价比实在太低。

2.2 方案二：C# WinForms——上手快，但天花板低到碰头

WinForms是我最早用过的上位机方案，当时图的就是一个“拖控件就能出界面”。确实，拉个按钮、拖个文本框，双击写事件，半天就能跑通一个相机连接和预览的demo。

但实际项目越做越深，WinForms的短板就开始暴露了。最核心的问题是界面表现力：在WinForms里做一个复杂的数据看板、自定义控件、高DPI适配，都要靠手写GDI+，代码量大还容易闪屏。现在的产线操作员对界面UI容忍度很低，丑界面直接会被投诉。

另外WinForms在异步和并发场景下容易踩线程地狱，UI线程和后台线程一交互就到处都是Invoke，代码很容易变成一团乱麻。虽然这个框架诞生二十多年了非常稳定，但它只适合写那种几十个参数、几页Tab的简单工具，稍微复杂一点的产线系统，就别硬撑了。

2.3 方案三：C# WPF——业务与界面兼顾的平衡点

WPF可以说是“戴着镣铐跳舞”的最佳选手。它最大的优势是UI与逻辑的清晰分离，配合MVVM模式，可以让业务代码不再被UI操作绑架。

这个方案我在后面会单独用一整章来讲，这里先给个结论：WPF在开发效率上比WinForms只低一点点，但界面表现力、自定义能力、数据绑定机制完全碾压；在性能上通过优化也能满足90%以上机芯预览场景的需求；SDK对接走P/Invoke调用C接口动态库，非常直接。

2.4 方案四：Python + PySide/PyQt——原型利器，产线勇者慎入

我见过不少视觉工程师喜欢用Python来写上位机，因为OpenCV、numpy这些库在Python里太好用了，算法验证非常快。确实，如果只是做一个算法demo、给客户演示一下效果，Python+PySide很合适。

但放到产线上，Python的问题非常致命。第一，GIL锁让多线程图像处理变成噩梦，相机多路并发采集时，Python后端很容易成为性能瓶颈。第二，打包问题多且杂——PyInstaller打出来的exe动不动几百MB，杀毒软件误报率还高。第三，现场环境兼容性差，工控机上Python环境版本一换，脚本全废。

Python方案适合做内部算法验证工具，指望它扛住产线24小时运行和三班倒的折腾，不太现实。

2.5 方案五：Electron/Web技术——界面很炫，代价是重量级

用Web技术写上位机是最近几年挺时髦的玩法，界面确实可以做得很漂亮，CSS动画、大屏看板信手拈来。但Electron打包出来的软件，一个安装包动辄一两百MB，内存占用长期在几百MB以上，对工控机来说简直是灾难。

更关键的问题是，Web技术访问底层硬件的能力太弱了。相机SDK通常要直接操作内存缓冲区，虽然有Node原生模块和ffi这类库可以做桥接，但性能和稳定性完全取决于桥接层写得好不好。调试相机这种延时敏感的场景，Web技术这一层桥接的损耗和不确定性，是很致命的。

此外，产线工控机很多不带GPU或者显卡驱动很老，Electron的GPU加速在远程桌面、虚拟机环境下经常白屏或黑屏，这种问题排查起来非常痛苦。

2.6 综合对比：谁是产线场景的“费米估算”赢家

把五套方案放在一起看，会发现一个很有意思的规律：在产线这个特定场景里，开发效率和部署维护的重要性，其实要高于极限性能和界面花哨程度。

Qt的性能虽然最强，但同样的工作量下，开发周期可能是WPF的2到3倍；Electron界面虽然最炫，但底层对接和运行体积决定了它不适合工控环境；Python虽然写起来最快，但性能和多线程问题是硬伤；WinForms稳定是稳定，但界面天花板太低，做不了现代感的产线UI。

WPF正好站在所有方格的交叉点上：开发效率高、界面表现力强、部署简单、SDK对接可行。它不是单项冠军，但它是综合得分最高的那个。

3. WPF为什么能成为最优解：不只是“界面好看”这么简单

很多人对WPF的印象就是“做界面比WinForms漂亮”，这是低估了它。WPF在设计哲学上，天生就是为“UI与逻辑分离”而生，这套哲学在产线软件开发中价值极大。

3.1 MVVM模式在上位机软件里的价值：再也不会被UI操作绑架

上位机软件开发中最常见的痛苦是：界面控件和业务逻辑缠在一起，改一个按钮行为，要找半天代码；相机回调里直接操作UI控件，一开多线程就崩；一个窗口里堆了两千行事件代码，连原作者自己都看不懂。

MVVM模式可以彻底解决这个问题。它的核心思想是，界面（View）、数据模型（Model）、视图模型（ViewModel）三者分离。UI只负责展示和转发用户操作，业务逻辑写在ViewModel里，通过数据绑定和命令机制通信。

举个例子，相机增益参数在界面上是一个Slider，拖动它需要实时更新相机里的增益值并刷新显示。用传统WinForms的写法，你要在Slider的ValueChanged事件里去调SDK，同时还要手动更新其他依赖控件的文本。用WPF的绑定，你只需要在ViewModel里定义一个Gain属性，界面Slider双向绑定到这个属性，属性setter里调用SDK下发参数，其他显示区域自动跟着变。

这套机制在产线批量配置参数、多页面联动、状态同步这些场景里，省下来的代码量是惊人的。而且因为业务逻辑在ViewModel里，不依赖任何UI控件，后期写单元测试也非常方便。

3.2 WPF的数据绑定与通知机制：参数同步不再靠手写刷新

WPF绑定的核心是INotifyPropertyChanged接口和依赖属性系统。简单理解就是，当后台数据变化时，界面会自动更新，不需要代码去主动调用textBox.Text = xxx。

这在多相机监控界面尤其好用。我在项目里做过多路相机状态看板，每台相机的温度、帧率、错误码、连接状态都要实时刷新。如果用传统的做法，至少得写几十行控件更新代码；用WPF绑定，我只需要让状态模型实现INotifyPropertyChanged，界面上的状态指示灯和数据文本全部自动联动，代码量直接砍掉一半以上。

WPF的绑定还有一个细节功能特别好用——值转换器（IValueConverter）。比如相机返回的是数字状态码，界面上要显示成“运行中”“异常”“未连接”，正常做法是写if-else判断，而用绑定加转换器，直接在XAML里写好转换规则就行，既整洁又不易出错。

3.3 自定义控件与渲染能力：产线大屏和看板不是问题

产线上经常需要做看板页面，把机芯状态、生产数量、缺陷率这些数据用大字、红绿灯、仪表盘的方式展示出来。这类界面如果用传统WinForms，得花大量时间在绘制上，而且容易闪烁；用WPF，Style、ControlTemplate、数据模板这些机制就是为这种需求设计的。

WPF还支持硬件加速渲染，动画和大屏刷新在远程桌面、触摸屏这些场景下，表现比GDI+绘制的应用好不少。而且WPF的XAML描述界面，意味着整个界面可以做成可配置的——由后台数据动态决定显示哪个模块、隐藏哪个按钮，产线换型的时候，不需要重新编译软件，改配置文件就行。

从这些角度回头看，WPF成为最优解，真正的原因不是单个功能有多强，而是它让“界面表现”和“业务逻辑”之间形成了解耦，使得上位机软件能在持续迭代、快速部署的要求下保持可维护性。

4. WPF上位机核心模块实现实录：从相机SDK到图像实时显示

理论说再多，不如代码来得实在。这里我把自己写的机芯调试工具里几个核心模块的实现思路和关键代码片段拿出来分享，这些代码经过产线实际运行验证，稳定性和可读性都过得去。

4.1 相机SDK封装层设计：用P/Invoke把C接口“翻译”成C#

工业相机SDK基本都是C接口的动态库，WPF这边通过P/Invoke调用是非常自然的方式。但直接在每个窗口里调用DllImport会让代码散乱不堪，我的做法是单独做一个CameraSdkWrapper静态类，把所有SDK调用集中管理。

public static class CameraSdkWrapper { [DllImport("MvCameraControl.dll", EntryPoint = "MV_CC_EnumDevices")] public static extern int EnumDevices(uint tlType, IntPtr deviceList); [DllImport("MvCameraControl.dll", EntryPoint = "MV_CC_CreateHandle")] public static extern int CreateHandle(ref IntPtr handle, IntPtr deviceInfo); [DllImport("MvCameraControl.dll", EntryPoint = "MV_CC_StartGrabbing")] public static extern int StartGrabbing(IntPtr handle); [DllImport("MvCameraControl.dll", EntryPoint = "MV_CC_RegisterImageCallBackEx")] public static extern int RegisterImageCallBackEx(IntPtr handle, ImageCallBack cb, IntPtr userContext); [DllImport("MvCameraControl.dll", EntryPoint = "MV_CC_StopGrabbing")] public static extern int StopGrabbing(IntPtr handle); [DllImport("MvCameraControl.dll", EntryPoint = "MV_CC_DestroyHandle")] public static extern int DestroyHandle(IntPtr handle); }

这里有几个细节很容易踩坑。一是P/Invoke的参数类型必须和C接口严格对应，比如句柄要用IntPtr而不是int，结构体要用MarshalAs指定布局；二是回调函数一定要用委托保存引用，防止GC回收导致SDK调用野指针；三是32位和64位的SDK版本要明确，DLL文件名一样但位数不同，加载到错误版本会直接崩溃。

封装好SDK调用之后，上层就可以像调用普通C#方法一样操作相机了，业务代码再也不用关心DllImport这些细节。

4.2 实时图像显示的优化：从卡顿到30帧流畅的完整过程

相机图像数据是字节数组，要在界面里显示，最直接的方式是转成Bitmap再赋给Image控件。但如果每帧都创建一个新的Bitmap，GC压力会非常大，界面也容易卡。

实测下来，最优的做法是用WriteableBitmap。它允许你直接操作像素缓冲区，绕过Bitmap对象频繁创建销毁的损耗。关键代码大致如下：

private WriteableBitmap _previewBitmap; private void OnImageReceived(byte[] buffer, int width, int height, int stride) { // 首次创建或尺寸变化时初始化 if (_previewBitmap == null || _previewBitmap.PixelWidth != width || _previewBitmap.PixelHeight != height) { _previewBitmap = new WriteableBitmap(width, height, 96, 96, PixelFormats.Bgr24, null); PreviewImage.Source = _previewBitmap; } // 直接把数据写入位图缓冲区 _previewBitmap.WritePixels( new Int32Rect(0, 0, width, height), buffer, stride, 0); }

这段代码有一个大坑：Image回调线程不是UI线程，直接在这里调WritePixels会报跨线程错误。要用Dispatcher.BeginInvoke把写入操作丢回UI线程。但也不能每一帧都丢，否则UI线程会被回调淹没。我的做法是用一个信号量控制刷新率：

private bool _isFramePending; private void OnImageReceived(byte[] buffer, int width, int height, int stride) { if (_isFramePending) return; _isFramePending = true; Application.Current.Dispatcher.BeginInvoke(() => { try { // 更新图像 UpdatePreview(buffer, width, height, stride); } finally { _isFramePending = false; } }, DispatcherPriority.Background); }

这样设置之后，相机的图像回调虽然以很高频率触发，但UI线程最多每帧渲染一次，不会出现界面卡死、拖拽窗口反应迟钝的问题。我还额外加了一个帧率计数器，方便在界面上直观地看到当前实际显示的帧率。

4.3 多相机并发处理：谁动了我的UI线程？线程模型一定要想清楚

产线上经常一台工控机接4到8台机芯，每台相机都在不停地回调图像。如果每台相机的回调都直接往UI线程塞数据，UI线程必然被堵死。我踩过的坑是：刚开始用8个Dispatcher.BeginInvoke往同一个界面刷新图像，结果界面卡得鼠标都挪不动。

正确思路是每台相机配置独立的图像队列和消费线程。相机回调只负责把数据放入队列，消费线程从队列取出图像再异步更新UI。这样即使一台相机出问题，也不影响其他相机的显示和控制。

这个架构的核心是队列的长度控制。如果相机的帧率是60FPS，而消费端处理能力只有30FPS，队列会越积越长，最终内存暴涨、延迟越来越大。我一般会把队列长度限制在5~10帧，超过就丢弃旧帧，保证永远显示的是最新图像。

4.4 配置文件的序列化：让每台设备都记住自己的参数

产线软件的参数配置，经常是写着写着就乱成一锅粥。我的经验是把所有设备参数统一放到一个配置模型中，用JSON序列化存盘。

public class DeviceConfig { public string DeviceName { get; set; } public double Exposure { get; set; } public double Gain { get; set; } public int TriggerMode { get; set; } public string IpAddress { get; set; } }

使用System.Text.Json或者Newtonsoft.Json，加载和保存都只需要几行代码，关键是保证保存时机。不要在用户点“保存”时才写盘，而是参数变化后设置一个自动保存定时器，延时2秒无新变化再写盘，这样既避免频繁磁盘写入，也能防止断电丢失最近修改。产线大量使用的“一键导出配置”“批量导入配置”，其实都是从这个配置模型展开的。

5. 产线适配全攻略：从工控机到操作工，一切都在和你想的不一样

在办公室开发环境里跑得飞快的软件，一部署到产线就各种问题：分辨率不对、中文乱码、权限被拦截、崩溃无日志。这一章专门讲产线适配里那些看起来很小、实际很致命的问题。

5.1 高DPI屏幕适配：界面模糊和错位是工控机的常态

很多工控机默认显示缩放是125%甚至150%，而WPF程序如果不做适配，界面会出现字体模糊、控件错位。解决之道是启动程序时声明DPI感知，并对界面布局使用Viewbox或动态缩放。

比较稳妥的写法是修改App.config和程序入口，让支持PerMonitorV2，但需要注意老的工业显示器或远程桌面未必支持高DPI特性，反而会触发异常。更保险的做法是保持传统DPI缩放，用WPF的布局机制让界面在缩放时自适应。实际操作中，我经常在程序启动时检测当前系统DPI，根据数值动态设置根元素的缩放比例，确保在任意缩放级别下界面都不变形。

5.2 参数批量下发与一键部署：产线不需要“个性化定制”

产线上的设备往往几十台参数一模一样，如果让操作工一台台手动设置，既浪费时间又容易出错。我的方案是在软件里提供一个“批处理模式”：先选一台“基准设备”调好参数，导出为JSON文件，然后一键下发到所有其他设备。

public bool ApplyConfigToAll(string json) { DeviceConfig cfg = JsonSerializer.Deserialize<DeviceConfig>(json); foreach (var cam in GetAllCameras()) { try { CameraSdkWrapper.SetExposure(cam.Handle, cfg.Exposure); CameraSdkWrapper.SetGain(cam.Handle, cfg.Gain); // ... } catch (Exception ex) { Log.Error($"{cam.Name} 配置下发失败: {ex.Message}"); return false; } } return true; }

批量下发最重要的一点是：下发过程中如果某台设备失败，必须明确提示是哪一台，并且不影响其他设备继续下发。我通常还会在下发之前先做一次全量校验，避免因为设备离线造成半途而废。

5.3 产线通讯协议：和PLC打交道的一线经验

机芯上位机软件很少孤立运行，它通常要和PLC或其他上位系统通信。最常用的是Modbus TCP和TCP Socket自定义协议。Modbus TCP在WPF里实现并不复杂，关键是处理好超时和重连机制。我踩过的坑是：PLC断电重连后，如果不主动重启通信线程，软件永远连不回来，必须写一个心跳监测，每隔几秒检测连接状态，掉线自动重连。

如果是自定义TCP协议，一定要注意多帧粘包和半包问题，用长度头前缀解决。以下是一个最简单的封包思路：

// 发送包格式：4字节长度 + 1字节命令 + N字节数据 byte[] data = Encoding.UTF8.GetBytes(payload); byte[] frame = new byte[5 + data.Length]; BitConverter.GetBytes(data.Length).CopyTo(frame, 0); frame[4] = command; data.CopyTo(frame, 5);

接收端先读取4字节长度，再按长度读取完整报文，解析命令字节走对应处理逻辑。这套模式在设备和PLC通信中非常经典，也能平滑扩展握手、心跳、数据上报等复杂逻辑。

5.4 权限管理与操作员界面：别让员工误点导致停线

产线软件通常有两种使用者：调试工程师和操作工。工程师需要完整权限，操作工只允许做启动、停止、简单参数调整。

我的做法是做一个登录环节，根据角色动态配置界面可用性。操作工登录时，禁用参数编辑、设备配置、系统设置这些模块；工程师登录才解锁全部功能。WPF里实现这个控制很方便，只需要在ViewModel里增加一个IsEditable属性，控件通过绑定自动切换启用禁用状态。

这个设计避免了很多次“操作工不小心点了某个参数导致整条产线参数错乱”的乌龙事件。即使是几台机器的产线，这个权限区分也非常值得做。

5.5 安装部署与运行环境：一个搬运工的自我修养

工控机上装软件，远程桌面连接、U盘拷文件是最常见的方式。安装包一定要做得尽量自包含，避免依赖在线安装框架。我用的打包工具是Inno Setup，他会把.NET Framework检测、所需DLL拷贝、桌面快捷方式、开机自启动选项都配置好。

还有一个细节：杀毒软件。WPF程序编译生成的exe在国产杀毒软件下经常被误报，尤其是用了P/Invoke调用动态库的时候。解决办法是给exe做数字签名，或者把程序目录加入杀毒软件白名单。在部署文档里写清楚这一条，能让产线IT配合顺畅很多。

日志系统也是部署阶段必须准备的。产线程序崩溃后如果没有日志，排查问题就是大海捞针。我在软件里用Log4Net或NLog记录所有关键操作和设备状态，日志文件按日期分文件存放，限制单个文件大小。这样无论是软件故障还是参数被改错，都能快速定位。

6. 常见问题与排查技巧实录：三班倒产线逼出来的经验

连续一年在产线现场摸爬滚打之后，我把最常遇到的上位机软件问题整理成了一份速查表，希望对看到这里的人有帮助。

6.1 界面卡顿、刷新延迟高

排查步骤：

• 先看相机回调帧率，如果回调本身跑满100FPS，那就可能是UI线程处理不过来。
• 检查是否在回调里做了耗时操作，比如文件保存、图像处理，应该拆到独立线程。
• 看Dispatcher.BeginInvoke的优先级，如果用了High，会阻塞其他UI操作，改用Background。
• 用Process Explorer检查CPU占用，如果UI线程长期占满一个核心，基本可以确定是上面某个原因。

6.2 相机连接后中途掉线，程序不自动恢复

这是产线最常见的故障之一。工业相机在长时间运行后，偶尔会因为USB带宽不足、网线松动、SDK内部错误导致数据流中断。我的经验是，上位机软件里加一个看门狗线程，每隔一定时间调用SDK的获取设备状态接口，一旦发现异常就自动重新拉起采集流程，同时把掉线时间和原因写入日志。

此外还有一个隐藏的坑：U3V相机（USB3 Vision）在设备重新枚举后，句柄会失效，必须重新创建设备信息，否则重连后无法采集。重连逻辑要写完整，不能只调用StartGrabbing。

6.3 WPF图像控件撕裂、闪烁

WPF的Image控件在快速刷新大尺寸图像时，偶尔会出现画面撕裂或闪烁。这通常是因为WriteableBitmap在写入时，渲染线程和写入线程发生了冲突。解决办法是把WritePixels操作放在UI线程，且只在渲染间隙（通过调度优先级控制）进行。

如果是高帧率相机，可以引入双缓冲机制，准备两个Bitmap交替使用，一个在当前帧显示，另一个下一帧写入，这样可以彻底避免撕裂。

6.4 配置保存后重启丢失

多半是配置文件写到了程序安装目录，而Program Files这类目录没有写权限。解决办法是把配置文件写到用户目录或程序数据目录，比如Environment.SpecialFolder.LocalApplicationData下面。此外，保存时要做好异常处理，如果写入失败要弹窗提示，不能静默失败。

6.5 内存持续上涨，最后OOM

WPF程序内存上涨有几个常见原因：图像回调创建的托管数组没有被及时释放、事件未取消订阅导致对象无法回收、WriteableBitmap写入了但没有正确清理。排查时用内存分析工具或者性能监视器看GC堆大小，如果持续上升，基本就是某个对象被长期引用了。

我遇到的最典型的问题是相机回调委托没有反注册，导致相机对象一直引用UI对象，UI窗口关闭了都没法回收。后来在窗口关闭事件里主动反注册回调，问题就消失了。

6.6 SDK初始化失败，提示找不到DLL

90%的情况是32位/64位不匹配，或者DLL拷贝的目录不对。WPF程序编译成x64，但SDK带了32位DLL，初始化必然失败。解决方法是要么把程序编译成x86，要么补齐x64的SDK运行库。另外有些SDK依赖VC运行库，工控机上没装的话也会报缺少DLL，可以在安装包里一起带上。

7. 写在最后的几个建议

这些经验和代码，都是从实际产线项目里一点点磨出来的。我个人最后想说三点。

第一，技术选型时，不要迷信某个技术栈的名气，要回到“部署环境、团队能力、SDK形态”这三个实际约束上去权衡。WPF在我的项目里是最优解，但如果你团队里全是写过多年C++的工程师，也许Qt的维护成本反而更低。

第二，代码架构一开始就按MVVM分层来做，哪怕只是写个调试小工具。等需求从“能显示图像”膨胀到“批量配置、权限控制、数据记录、异常恢复”，分层的价值就会显现得淋漓尽致。

第三，一定要在早期就考虑产线部署的事。日志系统、配置文件权限、DPI适配、杀毒软件白名单这些看起来不起眼的东西，往往是产线交付阶段消耗最多时间的部分。

最后再分享一个小技巧：WPF里面写产线软件的界面，尽量用基础的Grid和StackPanel布局，不要为了炫技用太多自定义动画。产线工控机配置低，动画多了反而拖慢整体响应，界面清爽、逻辑清晰，才是产线软件该有的样子。