WPF客户端实战：MVVM架构与MQTT对接车牌识别相机

这一期咱们直接进入正题，做WPF客户端。之前几期把项目背景、服务端接口、数据库设计都捋了一遍，这一期开始写界面、调逻辑、对接硬件。标题里写的是“客户端”，那我们就把客户端从零搭起来，包括MVVM架构、界面布局、DataGrid操作、MQTT协议对接车牌识别相机、Redis缓存读取、图表可视化这些核心模块。我尽量把每一段代码、每一个踩过的坑都写清楚，方便你照着做。

先说清楚这一期适合谁看。如果你已经会用WPF的基础控件，能写简单的绑定和事件，但遇到真实的项目还是不知道从哪下手——比如DataGrid怎么实现选中一行再删除、下拉框为什么总会多一行空白、相机回调的数据怎么在界面上实时刷出来——那就对了，这篇就是给你准备的。如果你还没接触过WPF，建议先花两天时间把绑定和依赖属性搞明白，否则看后面的内容会有点吃力。项目本身是一个物联网类的管理平台客户端，服务端已经提供了接口，我这边的任务就是把它做成一个能真正干活、不用天天返工的桌面程序。

1. 客户端整体架构与设计思路

1.1 为什么选MVVM而不是直接写事件

很多新手做WPF项目，上来就在Button的Click事件里写业务逻辑，窗体里堆一大坨代码。前期确实快，界面一多就崩了——一个窗体上千行代码，改个需求牵一发动全身，尤其是数据校验、异步操作、多界面联动，逻辑一复杂完全没法维护。

这个项目我选的是MVVM加Prism框架。MVVM的核心就是让界面（View）、数据（Model）和业务逻辑（ViewModel）分开，界面只负责展示和收集输入，ViewModel处理业务规则，Model管数据来源。这样带来的直接好处是：界面换皮肤、换布局，ViewModel一行不用改；单元测试可以直接测ViewModel，不用启动界面；多个视图也可以共用一个ViewModel，像同一份数据用列表和图表两种方式展示，绑到同一个属性即可。

Prism在MVVM之上又加了解耦能力。最明显的就是模块化——这个客户端有登录、监控大屏、车辆管理、报表统计、系统设置好几个功能区，按Prism的模块化思路，每个功能区独立编译、独立维护，以后增加功能不需要动原有代码。还有一个很实用的点是导航系统，通过INavigationAware接口管理界面跳转，ViewModel之间传递参数比手动拼构造函数优雅得多。

1.2 客户端的功能模块划分

这个客户端不是单机工具，它面对的是一个停车场管理平台的运营人员。所以我把它分成了五个子模块：

• 登录与权限：对接服务端的认证接口，拿到令牌之后缓存到本地，后续所有请求都带上令牌。
• 实时监控看板：通过MQTT订阅相机推送的车牌识别结果，在界面上实时弹出车辆入场/出场记录，同时联动大屏显示。
• 车辆管理：DataGrid显示所有车辆记录，支持按车牌号搜索、选中行删除、导出报表。
• 统计报表：用LiveCharts2展示车流量、收入趋势等图表数据，支持按时间段筛选。
• 系统设置：相机接入配置、MQTT连接参数、Redis连接串等，用Properties.Settings把配置保存到本地。

每个模块都是独立的Prism视图和视图模型，模块之间通过事件聚合器解耦。比如相机识别到了车牌，这个事件挂在EventAggregator上，监控看板和车辆管理页面各自决定要不要订阅、怎么响应，互不干扰。

1.3 分层依赖与目录结构

我建项目的习惯是solution下面分四个目录：View放界面，ViewModel放业务逻辑，Models放实体类，Services放服务。Services目录下再分HttpService、MqttService、RedisService、CameraService，各司其职。

code复制src
├─ App.xaml
├─ Views
│  ├─ LoginView.xaml
│  ├─ MonitorView.xaml
│  ├─ VehicleManageView.xaml
│  ├─ StatisticsView.xaml
│  └─ SettingsView.xaml
├─ ViewModels
│  ├─ LoginViewModel.cs
│  ├─ MonitorViewModel.cs
│  ├─ VehicleManageViewModel.cs
│  ├─ StatisticsViewModel.cs
│  └─ SettingsViewModel.cs
├─ Models
│  ├─ VehicleRecord.cs
│  ├─ CameraDevice.cs
│  ├─ MqttMessage.cs
│  └─ LoginResult.cs
├─ Services
│  ├─ HttpService.cs
│  ├─ MqttService.cs
│  ├─ RedisService.cs
│  └─ CameraService.cs
└─ Commons
   ├─ EventMessages.cs
   └─ RelayCommand.cs

这套结构不复杂，每个文件夹的作用看一眼就懂。最关键的约定是：ViewModel绝对不能直接new View，界面跳转统一用Prism的导航请求。这样解耦之后，每个文件都能单独测试、单独替换，这是客户端项目能持续迭代的基础。

2. 界面布局与控件实战

2.1 主窗体框架设计

WPF客户端的主窗体不建议用那种乱七八糟的布局，所有控件直接堆在Grid里，后期加功能会非常痛苦。我的做法是整体分成三栏：左侧导航栏固定宽度200像素，中间为主内容区，右侧为实时消息栏。左侧用ListBox或者RadioButton做导航菜单，中间放一个ContentControl作为Prism的导航宿主，右侧放实时滚动日志。

主窗体的XAML骨架大致这样：

xml复制<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="200"/>
        <ColumnDefinition Width="*"/>
        <ColumnDefinition Width="300"/>
    </Grid.ColumnDefinitions>

    <!-- 左侧导航菜单 -->
    <Border Grid.Column="0" Background="#2D3A4B">
        <StackPanel>
            <RadioButton Content="实时监控" GroupName="nav" 
                         Command="{x:Static infra:PrismCommands.NavigateCommand}"
                         CommandParameter="MonitorView"/>
            <RadioButton Content="车辆管理" GroupName="nav"
                         Command="{x:Static infra:PrismCommands.NavigateCommand}"
                         CommandParameter="VehicleManageView"/>
            <RadioButton Content="统计报表" GroupName="nav"
                         Command="{x:Static infra:PrismCommands.NavigateCommand}"
                         CommandParameter="StatisticsView"/>
            <RadioButton Content="系统设置" GroupName="nav"
                         Command="{x:Static infra:PrismCommands.NavigateCommand}"
                         CommandParameter="SettingsView"/>
        </StackPanel>
    </Border>

    <!-- 主内容区 -->
    <ContentControl Grid.Column="1" prism:RegionManager.RegionName="MainContentRegion"/>

    <!-- 右侧实时消息栏 -->
    <ListBox Grid.Column="2" ItemsSource="{Binding RealtimeLogs}"/>
</Grid>

导航这里有个细节要提醒：RadioButton的GroupName要一致，不然后期会出现在两个菜单同时选中的怪现象。另外CommandParameter里传的是视图名称字符串，Prism会根据它解析到对应的注册视图，所以Views目录下的类名要和这里完全一致。

2.2 样式资源统一管理

客户端界面最容易出的问题是控件样式五花八门，同一个Button在不同页面长得不一样。做项目的第一天就要把全局样式建好，放到App.xaml的Resources里，后续所有界面都引用统一的样式，改主题只改一处。

我这里定义了几个基础样式：

xml复制<Style x:Key="BaseButtonStyle" TargetType="Button">
    <Setter Property="Background" Value="#4A90D9"/>
    <Setter Property="Foreground" Value="White"/>
    <Setter Property="BorderThickness" Value="0"/>
    <Setter Property="Height" Value="32"/>
    <Setter Property="Width" Value="90"/>
    <Setter Property="Cursor" Value="Hand"/>
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="Button">
                <Border x:Name="border" Background="{TemplateBinding Background}" CornerRadius="4">
                    <ContentPresenter HorizontalAlignment="Center" VerticalAlignment="Center"/>
                </Border>
                <ControlTemplate.Triggers>
                    <Trigger Property="IsMouseOver" Value="True">
                        <Setter TargetName="border" Property="Background" Value="#357ABD"/>
                    </Trigger>
                    <Trigger Property="IsPressed" Value="True">
                        <Setter TargetName="border" Property="Background" Value="#2E6DA4"/>
                    </Trigger>
                    <Trigger Property="IsEnabled" Value="False">
                        <Setter TargetName="border" Property="Background" Value="#B0BEC5"/>
                    </Trigger>
                </ControlTemplate.Triggers>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

这个样式把Button默认的边角、背景、点击效果全部重写了一遍，统一成圆角扁平风格。关键点在于ControlTemplate里的触发器，鼠标悬停和按下的颜色变化都是在这里实现的，而不是在后台代码里改颜色。这样写的好处是所有用这个样式的按钮自动获得一致的交互反馈，不会出现某个页面按钮点击了没反应的问题。

颜色、圆角、尺寸这些样式常量也可以单独抽成资源字典。我在项目里建了一个Colors.xaml专门管理颜色，比如PrimaryBrush、SuccessBrush、DangerBrush、TextPrimaryBrush，后期如果客户说要换个品牌色调，只改这一个文件就行——这个投入从一开始就是值得的。

2.3 DataGrid高级应用实战

DataGrid是WPF客户端里最常用的表格控件，但默认样式很难看，而且功能也缺很多。这个项目的车辆管理页面就用到了DataGrid的几个核心场景：加载数据、选中行变色、删除选中行、复选框多选、单元格编辑。

先说我踩过的一个坑：默认情况下，DataGrid选中一行时，整行会变成蓝色背景，而且这个颜色在系统深色主题和浅色主题下显示效果不一样。如果不重写样式，用户根本看不清选中的是哪一行。解决方案是重写RowStyle中的触发器：

xml复制<DataGrid.RowStyle>
    <Style TargetType="DataGridRow">
        <Style.Triggers>
            <Trigger Property="IsSelected" Value="True">
                <Setter Property="Background" Value="#E3F2FD"/>
                <Setter Property="BorderBrush" Value="#4A90D9"/>
                <Setter Property="BorderThickness" Value="1"/>
                <Setter Property="Foreground" Value="#1A237E"/>
            </Trigger>
        </Style.Triggers>
    </Style>
</DataGrid.RowStyle>

注意这里不能用ControlTemplate重写整行模板，那样会导致DataGrid的虚拟化性能下降。用Style触发器覆盖背景和边框就足够了。另外，如果DataGrid的SelectionUnit默认是FullRow，点击单元格时也会选中整行；如果你希望只能通过点击行首选中，需要把SelectionUnit改成FullRow、SelectionMode改成Single，具体看业务需求。

然后是复选框列。需求里有一项是“DataGrid某一行checkbox选中，点击按键删除”。我的实现是增加一个DataGridCheckBoxColumn作为首列，和ViewModel里的IsSelected属性双向绑定。这里有一个很容易出问题的点：DataGridCheckBoxColumn绑定的IsSelected属性必须在实体类里实现INotifyPropertyChanged，否则勾选后ViewModel收不到值。 而且如果你用的是自动生成的列，绑定可能直接失效，所以我都是把列全部手动声明出来，这样每个列的绑定目标都清清楚楚。

xml复制<DataGrid ItemsSource="{Binding VehicleRecords}" AutoGenerateColumns="False"
          SelectedItem="{Binding SelectedVehicleRecord}">
    <DataGrid.Columns>
        <DataGridCheckBoxColumn Header="选择" Binding="{Binding IsSelected, UpdateSourceTrigger=PropertyChanged}" Width="60"/>
        <DataGridTextColumn Header="车牌号" Binding="{Binding PlateNo}" Width="120"/>
        <DataGridTextColumn Header="车辆类型" Binding="{Binding VehicleType}" Width="100"/>
        <DataGridTextColumn Header="入场时间" Binding="{Binding EntryTime, StringFormat='yyyy-MM-dd HH:mm:ss'}" Width="160"/>
        <DataGridTextColumn Header="出场时间" Binding="{Binding ExitTime, StringFormat='yyyy-MM-dd HH:mm:ss'}" Width="160"/>
        <DataGridTextColumn Header="停车费用" Binding="{Binding Amount, StringFormat='F2'}" Width="100"/>
        <DataGridTextColumn Header="状态" Binding="{Binding Status}" Width="80"/>
    </DataGrid.Columns>
</DataGrid>

页面里的“删除选中行”按钮，逻辑很简单：遍历当前集合，把所有IsSelected为true的项收集起来，再从集合移除，同时调服务端接口删除记录。这里有一个大坑：绝对不能直接在foreach里修改正在遍历的集合。 我最初写的时候直接在foreach里调Remove，跑到一半就抛异常“集合已修改”，后来改成先ToList再循环删除就没事了。

csharp复制private void DeleteSelectedRows()
{
    var selected = VehicleRecords.Where(x => x.IsSelected).ToList();
    if (selected.Count == 0)
    {
        MessageBox.Show("请先勾选要删除的行");
        return;
    }
    foreach (var item in selected)
    {
        VehicleRecords.Remove(item);
    }
}

DataGrid还有两个折磨过我的细节。第一个是双击表头自动调整列宽后，列宽会变得很离谱，有时候窄到看不到内容，有时候宽到把表格撑爆。解决方法是给DataGrid列设置MinWidth，同时把ColumnWidth设成SizeToHeader或者用固定宽度。第二个是TextColumn默认不支持换行，如果单元格内容很长，会显示成一行被截断；要换行就得用DataGridTemplateColumn，里面放一个TextBlock，设置TextWrapping="Wrap"，同时行的Height不能是固定值，否则内容还是会被裁掉。这个在StackPanel里的TextBlock换行也适用——StackPanel里放TextBlock想换行，必须同时设置TextWrapping="Wrap"和给TextBlock一个有限的宽度，否则StackPanel会无限扩大宽度，TextBlock永远不会换行。

2.4 ComboBox的坑与美化

ComboBox这个控件看上去简单，实际用起来坑不少。我这次遇到的是项目热词里也提到的“wpf combobox 下拉框 末尾 空白”。现象是：下拉列表设置了ItemsSource，运行时最后一行的下面会多出来一段空白，怎么都去不掉。

排查下来发现，问题出在ComboBox默认的ToggleButton和Popup的布局上。如果给ComboBox设置了较长的显式宽度，但ItemTemplate里的内容宽度不够，下拉框会把空白区域算进去。解决办法有两个：

一是给ComboBox设置MaxDropDownHeight，防止下拉框因为内容超高而出现多余空白。二是直接重写ComboBox的ItemContainerStyle，把Padding和Margin清零：

xml复制<ComboBox ItemsSource="{Binding CameraList}" SelectedItem="{Binding SelectedCamera}">
    <ComboBox.ItemContainerStyle>
        <Style TargetType="ComboBoxItem">
            <Setter Property="Padding" Value="2"/>
            <Setter Property="Margin" Value="0"/>
        </Style>
    </ComboBox.ItemContainerStyle>
</ComboBox>

如果还是不行，那么就要检查ComboBox的Width是否比内容宽很多，把Width设为Auto，让下拉框根据内容自适应宽度，空白问题基本就消失了。其实这个坑的根源是WPF默认的ComboBox样式为了显示“箭头”占位符，在内容区右侧预留了固定空间，当内容宽度小于这个预留空间时就会露出空白。实在绕不开的时候直接换成第三方UI框架，比如HandyControl或者MaterialDesignInXAML，它们的ComboBox默认样式更干净，也更好自定义。这个项目我为了赶进度没有引入第三方框架，但如果你不介意包体积，用HandyControl可以省掉很多自绘样式的活。

2.5 ListView美化与动态按钮

ListView在这个项目里用来展示右侧的实时消息列表。默认ListView的样式非常素，横向滚动条丑、行高也不对，而且鼠标悬停时的效果几乎看不出来。我重写了ListViewItem的样式，让它看起来像个卡片列表：

xml复制<Style x:Key="CardListViewItemStyle" TargetType="ListViewItem">
    <Setter Property="HorizontalContentAlignment" Value="Stretch"/>
    <Setter Property="Padding" Value="8"/>
    <Setter Property="Margin" Value="0,2,0,2"/>
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="ListViewItem">
                <Border x:Name="border" Background="Transparent" CornerRadius="4" Padding="{TemplateBinding Padding}">
                    <ContentPresenter/>
                </Border>
                <ControlTemplate.Triggers>
                    <Trigger Property="IsMouseOver" Value="True">
                        <Setter TargetName="border" Property="Background" Value="#F5F7FA"/>
                    </Trigger>
                    <Trigger Property="IsSelected" Value="True">
                        <Setter TargetName="border" Property="Background" Value="#E8F0FE"/>
                    </Trigger>
                </ControlTemplate.Triggers>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

这里有一个细节：如果ListViewItem的Template里不设HorizontalContentAlignment为Stretch，内容就无法填满整行，鼠标悬停高亮只覆盖内容那一小块，视觉效果会很难看。这个坑我调了很久才反应过来。

动态创建Button的需求也在这个项目里出现了——车辆类型有很多种，每种类型需要不同的筛选按钮。一开始我是直接在XAML里写死Button，后来类型一多就发现没法维护。改成了用ItemsControl绑定到一个类型列表，每个类型自动生成一个Button，通过CommandParameter把类型传给筛选命令：

xml复制<ItemsControl ItemsSource="{Binding VehicleTypes}">
    <ItemsControl.ItemsPanel>
        <ItemsPanelTemplate>
            <WrapPanel/>
        </ItemsPanelTemplate>
    </ItemsControl.ItemsPanel>
    <ItemsControl.ItemTemplate>
        <DataTemplate>
            <Button Content="{Binding}" Tag="{Binding}"
                    Command="{Binding DataContext.FilterCommand, RelativeSource={RelativeSource AncestorType=ItemsControl}}"
                    CommandParameter="{Binding}"
                    Style="{StaticResource BaseButtonStyle}" Margin="4"/>
        </DataTemplate>
    </ItemsControl.ItemTemplate>
</ItemsControl>

这里用RelativeSource向上找到ItemsControl的DataContext，即ViewModel，然后绑定到FilterCommand。CommandParameter就是类型名称。如果直接在DataTemplate里写{Binding FilterCommand}，会因为DataContext是类型字符串而绑定失败，这是新手最容易懵的地方。

3. 数据交互与核心业务实现

3.1 车辆数据的CRUD与异步加载

客户端的数据源有两块，一是服务端HTTP接口返回的历史数据，二是MQTT推送的实时数据。我们先说HTTP接口这块。

服务端接口返回的是JSON数组，我用HttpClient封装了一个HttpService，统一处理令牌、超时、异常重试逻辑。WPF里的HTTP请求必须用异步，不然界面会卡死。我在ViewModel里调用的时候，先用一个IsLoading标志控制加载状态，界面上显示“加载中...”，数据回来后绑定到ObservableCollection。

ObservableCollection有个特性容易被忽略：它只能在UI线程中修改。如果异步请求的回调在后台线程里直接给集合Add，界面会抛“调用线程无法访问此对象”的异常。解决方案是回到UI线程再操作集合，或者用Dispatcher：

csharp复制private async Task LoadVehicleRecordsAsync()
{
    IsLoading = true;
    try
    {
        var data = await _httpService.GetVehicleRecordsAsync();
        Application.Current.Dispatcher.Invoke(() =>
        {
            VehicleRecords.Clear();
            foreach (var item in data)
            {
                VehicleRecords.Add(item);
            }
        });
    }
    catch (Exception ex)
    {
        MessageBox.Show($"加载车辆数据失败：{ex.Message}");
    }
    finally
    {
        IsLoading = false;
    }
}

我见过很多同事直接用Task.Run去加载数据，回来后不管线程上下文直接操作集合，隔几分钟就崩一次。这个代码的定型建议是：所有异步操作返回后，凡是涉及UI集合修改的，统一包一层Dispatcher.Invoke，不是性能瓶颈，但能避免一堆偶发崩溃。

3.2 MQTT协议对接车牌识别相机

这个项目对接的相机是海康、大华这类主流厂商的型号。它们都支持通过MQTT把车牌识别结果推送到指定Topic。先说明一下，这里不是做设备端开发，而是做平台客户端去接收设备的消息，所以不需要了解相机SDK的内部实现，只要按协议规范订阅和解析即可。

我做了一个MqttService，用M2Mqtt库连接MQTT服务器，订阅相机推送Topic。收到消息后解析JSON，提取车牌号、时间、图片路径等信息，发布一个“车辆识别事件”到Prism的EventAggregator，界面监听这个事件自动刷新。

核心代码大致是这样：

csharp复制public class MqttService : IMqttService
{
    private MqttClient _client;
    private readonly IEventAggregator _eventAggregator;

    public MqttService(IEventAggregator eventAggregator)
    {
        _eventAggregator = eventAggregator;
    }

    public void Connect(string brokerHost, int brokerPort, string clientId)
    {
        _client = new MqttClient(brokerHost, brokerPort, false, null, null, MqttSslProtocols.None);
        _client.MqttMsgPublishReceived += OnMessageReceived;
        _client.Connect(clientId);
        _client.Subscribe(new[] { "camera/recognized" }, new[] { MqttMsgBase.QOS_LEVEL_AT_LEAST_ONCE });
    }

    private void OnMessageReceived(object sender, MqttMsgPublishEventArgs e)
    {
        var payload = Encoding.UTF8.GetString(e.Message);
        var msg = JsonConvert.DeserializeObject<MqttMessage>(payload);
        _eventAggregator.GetEvent<VehicleRecognizedEvent>().Publish(msg);
    }
}

这里有几个容易出错的地方：一是订阅Topic必须和相机配置里设置的一致，很多厂商默认Topic里有设备序列号前缀，需要看设备文档确认；二是QoS级别至少要选QOS_LEVEL_AT_LEAST_ONCE，不然网络抖动时会丢消息，车牌识别这种实时性要求高的场景丢一条就少一条记录；三是MQTT客户端如果断线了，需要设计重连机制，我在Connect里加了一个定时器，如果连接状态为断开就每隔5秒重试一次。

MQTT协议用到的核心概念就是发布/订阅。 相机是发布者，客户端是订阅者。你把客户端想象成一个订阅了“车牌识别消息”报纸的人，相机的识别结果一“出版”，你就能收到。MQTT服务器就是那个邮局，负责中转消息。这样设计的好处是，即使客户端不在线，消息也会在服务器上短暂留存（取决于遗嘱消息和会话机制），重连后可以补收，这个项目里我把保留消息开启，保证掉线期间的数据不丢。

3.3 HTTP接口与登录鉴权

登录这块，服务端返回一个Token，客户端把它存到内存和本地配置里。后续所有HTTP请求都在Header里带上Authorization。这里我踩过一个很经典的坑：HttpClient不建议每次请求都new，特别是频繁调接口的时候，会导致端口耗尽或连接超时。 我是在HttpService里用一个静态的HttpClient实例，设置好默认请求头，整个客户端生命周期共用。

csharp复制public class HttpService
{
    private static readonly HttpClient _httpClient = new HttpClient();
    private string _token;

    public void SetToken(string token)
    {
        _token = token;
        _httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token);
    }

    public async Task<string> GetAsync(string url)
    {
        var response = await _httpClient.GetAsync(url);
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    }
}

关于登录状态的管理，我做了一个简单但实用的Session类，保存当前登录用户、Token、角色权限。在Prism导航的时候，如果Session里没有Token，导航会弹回登录页。这个逻辑写在一个全局的导航拦截器里，比在每一个ViewModel的构造方法里判断要省事得多。

3.4 Redis客户端的可视化读取

项目热词里提到了“redis客户端可视化工具”，这个我确实用上了。服务端把车辆进场的缓存数据存在Redis里，键是车牌号，值是入场时间。客户端需要读取这些缓存来展示在场车辆信息，所以我引入了Redis客户端。

我自己在项目中一般用两种方式：开发调试时用Another Redis Desktop Manager，看数据非常直观，适合排查服务端写入的数据结构和过期时间；但程序内部访问Redis，用的是StackExchange.Redis客户端库。这个库的API设计得很简洁：

csharp复制using StackExchange.Redis;

var redis = ConnectionMultiplexer.Connect("127.0.0.1:6379");
var db = redis.GetDatabase();
RedisValue value = db.StringGet("vehicle:entry:京A12345");

需要注意的是，ConnectionMultiplexer是线程安全的，应该全局只创建一次，不要每个请求都Connect。 另外，Redis里存储的值如果是中文，可能会有编码问题，服务端写入时用UTF8，客户端读取时也按UTF8解析。我在调车牌数据时碰到过低级错误：服务端存的字符串带引号，客户端没去掉就直接显示，边界上多了个双引号。后来统一用JsonConvert.DeserializeObject解析，这类问题就消失了。

3.5 TLS连接错误的排查

项目热词里有一条“创建tls客户端凭据时发生严重错误。内部错误状态为10013”，这个我在对接相机的时候也确实遇到过，当时排查了很久。现象是：客户端通过HTTPS或者TLS连接相机的服务接口时，系统抛出一个“内部错误状态为10013”的异常。10013是Windows套接字错误WSAEACCES，表示权限被拒绝。用大白话说，就是系统认为你的程序没有权限去访问某个网络资源。

我最终排查出来的原因有两类。第一类是端口冲突或被防火墙拦截，相机的某个HTTPS端口被占用了，程序连接时被系统拦了。第二类是证书校验问题，相机的自签名证书不受系统信任，TLS握手阶段就被终止。解决办法是：如果只做开发联调，可以在代码里暂时跳过证书验证；但正式环境不要这样干，会有安全风险，还是要将相机证书导入到系统的受信任根证书列表。

第三类是杀毒软件或者网络策略拦截，某些企业电脑上自带的终端安全管理软件会拦截程序的出站连接，导致WSAEACCES。这种问题在开发机上很难还原，只能在目标环境测试时看Windows事件日志确认具体是哪个进程拦截的。这类连接错误从客户端消息看往往只有“严重错误”四个字，非常模糊，必须在服务提供方、防火墙策略、证书信任三个方向同时排查，而不是只盯着一行异常信息看。

4. 图表可视化与客户端性能优化

4.1 LiveCharts2的接入与展示

统计报表模块我用了LiveCharts2。这是WPF社区里比较活跃的开源图表库，支持折线图、柱状图、饼图，动画效果流畅，API比老版本的LiveCharts更现代化。

接入方式不复杂，安装包之后在XAML里声明：

xml复制xmlns:lvc="clr-namespace:LiveChartsCore.SkiaSharpView.WPF;assembly=LiveChartsCore.SkiaSharpView.WPF"

<lvc:CartesianChart Series="{Binding SeriesCollection}" 
                    XAxes="{Binding XAxes}" 
                    YAxes="{Binding YAxes}"/>

在ViewModel里按时间范围生成图表数据。比如展示最近7天的车流量，我先把服务端返回的记录按日期分组，然后映射成LineSeries<DateTime, double>：

csharp复制SeriesCollection = new ISeries[]
{
    new LineSeries<DateTime, double>
    {
        Name = "车流量",
        Values = groupedData.Select(x => new DateTimePoint(x.Date, x.Count)).ToArray(),
        Stroke = new SolidColorPaint(new SKColor(74, 144, 217)),
        Fill = null
    }
};

LiveCharts2这里要注意的是，它默认使用SkiaSharp渲染，运行时需要包含SkiaSharp相关的Native库。如果部署的机器上有报错提示找不到libSkiaSharp，检查一下所有项目的目标平台是否一致，最好统一成x64，否则容易在32位/64位切换时崩溃。

另外一个经常被忽略的问题是：图表数据更新时，SeriesCollection建议整个重新赋值，而不是修改原Series里的Values。因为图表控件对ObservableCollection的监听有限，修改内部值经常不会触发重绘，整个替换最稳定。

4.2 客户端性能与后台线程处理

WPF客户端的卡顿大多数不是因为WPF本身慢，而是把耗时操作放在了UI线程。这里我用了几条硬性规则：

• HTTP请求、MQTT消息处理、Redis读写全部走异步方法，不要用.Result或.Wait()阻塞等待。
• 大集合的遍历和筛选用LINQ，但要注意LINQ是延迟执行的，如果后面要多次遍历，先.ToList()固化结果。
• 图片缩略图这种操作放到Task.Run里。
• 实时日志列表不能无限增长，我设置了最多保留200条，超出就移除最早的一条，不然界面会越跑越卡。

数据量上来的时候，DataGrid的加载也会明显变慢。一万条数据处理都很吃力。优化方案是给DataGrid开启虚拟化，这是WPF自带的能力，只要ItemsSource是实现了IList接口的集合，并且ScrollViewer.CanContentScroll="True"（默认就是True），就能生效。要注意的是，如果你的DataGrid放在ScrollViewer里，虚拟化会失效，因为外层ScrollViewer把所有内容都当成一个整体渲染了。 不要在DataGrid外面随便包一层带滚动的容器。

4.3 设置页与配置持久化

系统设置页面要保存相机列表、MQTT参数、Redis连接串。WPF有自带的配置系统Properties.Settings，简单实用，不需要引额外的JSON库。但有一点要说明，Settings保存的是“用户级配置”，即安装目录下或用户目录下会生成配置文件，卸载重装可能保留也可能不保留，看部署方式。

更稳妥的做法是把配置存成JSON文件放在程序目录下，自己封装一个ConfigService。读的时候如果文件不存在就给默认值，写的时候用JsonConvert.SerializeObject格式化一下，方便排错。

csharp复制public class ConfigService : IConfigService
{
    private readonly string _configPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "config.json");

    public AppConfig Load()
    {
        if (!File.Exists(_configPath)) return new AppConfig();
        var json = File.ReadAllText(_configPath);
        return JsonConvert.DeserializeObject<AppConfig>(json);
    }

    public void Save(AppConfig config)
    {
        var json = JsonConvert.SerializeObject(config, Formatting.Indented);
        File.WriteAllText(_configPath, json);
    }
}

这个做法有个好处是，客户现场部署时可以直接改config.json里的IP地址和端口，重启客户端就生效，不用重新编译发布。当然，这种直接暴露配置文件的模式也存在风险，需要注意访问权限，避免普通用户乱改导致系统起不来。

5. 常见异常与调试技巧

5.1 常见问题速查表

这一期项目做下来，我最想总结的是那些在搜索引擎里反复被问、但答案总是模棱两可的问题。我把这期实战中实际遇到并解决的异常整理成了一张速查表，遇到类似问题直接对照排查。

5.2 调试WPF界面的实用技巧

WPF界面的调试比Web复杂，因为你不容易看清哪个控件的Margin或Padding出了问题。我的经验是Visual Studio的实时可视化树和属性窗口一定要熟练使用——运行程序后，在调试状态下，点“实时可视化树”可以直接在界面上选中控件，定位到对应的XAML元素，查看运行时实际计算出来的尺寸、位置、颜色。很多布局问题靠肉眼看代码看不出来，但放在实时可视化树里一下就暴露了。

另外，在ViewModel的调试上，我用了一个很小的技巧：在RelayCommand的Execute方法入口加上断点，然后观察Sender和CommandParameter的值。如果CommandParameter为null，说明绑定那边Context或者绑定路径有问题。如果命令根本没有执行，先检查CanExecute方法是否返回了false——这个是新手最容易忽略的，按钮看起来能点，但命令的CanExecute没有返回true，点击事件根本不会触发。

5.3 数据绑定失败的隐蔽原因

有一种很隐蔽的绑定错误：属性名拼写正确、DataContext设置也没问题，但界面就是显示不出来。这种情况十有八九是绑定的源属性没有变化通知，就是没有实现INotifyPropertyChanged。WPF的绑定默认是单向，并且只在初始化时读取一次，如果后面的数据是你通过代码更新的，UI不会自动刷新。要记住，WPF绑定的灵魂就是INotifyPropertyChanged，只要想动态更新界面，属性就必须实现它。

还有另外一种更隐蔽的情况是绑定路径写错了，但编译期不报错。比如把SelectedItem写成了SelectedValue，或者把ItemsSource写到了DataGrid而非DataGrid.Columns下的某个列。这种错误在运行时不会崩溃，只会默默失效，排查起来极其耗时。处理方法是：在调试时打开输出窗口，看有没有绑定错误信息，或者给绑定的ViewModel属性设置默认值，看界面是否正确显示默认值。如果属性名和路径完全没问题，还可以考虑用x:Debug标记临时输出绑定值——但不如直接用实时可视化树检查可靠。

5.4 常用工具总结

做WPF客户端开发，有几个工具是必须备齐的。开发环境是Visual Studio 2022，装好“.NET桌面开发”工作负载，如果要用Prism，再从NuGet安装Prism.Unity包。数据管理方面，SQL Server用SSMS，Redis用Redis Desktop Manager，看看键值和过期时间很方便。抓包工具我用Fiddler，排查HTTP接口请求很关键，尤其是登录Token有没有传对、响应数据结构和预期是否一致。MQTT调试用MQTTX，可以手动订阅相机的Topic，观察相机推上来的数据结构，这个对协议对接测试特别有用——不用等到相机真正出车，直接在MQTTX里发一条模拟消息就能验证客户端的解析逻辑。

另外，单元测试也不要忽略。ViewModel里的核心逻辑，比如删除选中行、数据分组统计，都可以在测试工程里直接调用。WPF本身不好做自动化的界面测试，但把业务逻辑从界面里抽出来后，纯逻辑的测试其实很简单，这也是MVVM帮我保住项目质量的最大回报。

6. 项目收尾与上线的几个建议

这期内容写到这里，客户端的主要模块已经全部跑通。最后我再分享几个上线前一定要做的细节检查，这些都是在真实交付中才能体会到的经验。

第一，部署机器的环境。WPF客户端如果是.NET Framework版本，目标机器一定要装对应版本的.NET Framework。如果用.NET 6或.NET 8开发，可以走单文件发布，把所有依赖打包成一个exe，部署时省了不少事。但要注意，依赖SkiaSharp的LiveCharts2在单文件发布模式下，Native库的路径处理会有坑，我最后是把Native库dll单独拷到发布目录才解决。

第二，异常日志。客户端在客户现场崩溃，没有日志根本没法排查。我在项目里接入了NLog，把日志写到一个logs目录，按日期滚动。凡是HTTP请求失败、MQTT断线重连、未知异常，全部记录日志。客户报障时，让人远程把日志目录打包回来，问题定位效率能提升一倍以上。

第三，客户端的自动更新。桌面客户端不像Web，改一个bug还要重新安装。如果项目周期长、迭代快，建议从一开始就设计一个简单的自动更新机制：启动时请求服务端的一个版本接口，如果版本号不一致，就下载新版本压缩包，解压覆盖，然后重启。这个机制我最早的一版是手写的，大概花了半天时间，后来一直复用，比每次用U盘去现场更新省力太多。

第四，性能的底线。客户端打开时间超过3秒、切换页面卡顿超过1秒，用户的体感就很差了。我这个项目的监控看板因为要实时刷新表格和图表，一开始在低配工控机上明显掉帧。优化思路是：实时消息不是每条都立刻渲染到DataGrid，而是先缓存，每秒批量刷新一次；图表的动画关闭，或者把动画时长缩短到100毫秒以内。做了这两个改动之后，工控机上也能保持30帧以上的流畅度。

第五，做好用户操作反馈。客户端桌面应用和Web不同，点击按钮后如果长时间没有响应，用户就会以为程序死了。我统一在异步命令执行期间，用状态栏和按钮禁用两种方式来反馈操作状态。比如加载数据时，按钮IsEnabled设为false，文字改成“加载中...”，数据回来后恢复。这个细节能明显提升软件的专业感，也是我后来在自己项目里一直坚持的做法。

最后说一点这五期持续更新下来我个人的体会：WPF客户端最难的不是单个控件，而是把MVVM、异步、消息、通信这些知识组织成一个能稳定运行的整体。很多初学者学WPF总是停留在到处双击事件写代码的阶段，一上手真实项目就乱套。这一期的实战核心就是告诉你，一个正规的桌面客户端应该长什么样、应该怎么分层、碰到问题应该从哪些方向排查。照着这个思路做，哪怕不用Prism，也能写出结构清楚、能维护的客户端。如果你已经把这个项目的客户端完整跑起来了，下一期可以继续研究服务端的高并发处理以及客户端与服务端的联调优化。