我是升讯威在线客服与营销系统的作者，一名独立开发者。我用了近 5 年的时间，把私有化在线客服系统做到了市场第一名。可以看这里 5年，一个程序员是如何把私有化在线客服系统做到第一名的。
在这 5 年中，我的一些想法也随着时代的发展在发生变化，例如我曾经坚持认为 Mac 版本的客服工作台，是不需要的，客服办公肯定用的全是 Windows 啊。
也许在多年前这是基本成立的，但最近一年左右，经常有人问我客服工作台能不能支持 Mac、有没有 Mac 版本的开发计划，我通过对网站的访问数据统计也观察到使用 Mac 的访问者越来越多。
特别是前几个月，因为我没有实现对 Mac 版客服工作台的支持，错失了一个很可能是大客户的合作机会！这个客户同样是外贸场景，在行业内有一定影响力，真的是连客服在内都用 Mac 来办公。
种种迹象之下，我的想法开始变化（所以说人不能太固执），我开始调研客服工作台的 Mac 版问题，调查技术实现的路线和成本。
方案比较
纯 Web 版在线客服工作台？
工业级的在线客服系统不太合适用纯 Web 方案，这个问题我在之前的博客中有过许多讨论，这里不再赘述。
Mac 原生开发（Swift / SwiftUI）？
最先被想到的方案一定是使用 Apple 官方的 Swift 与 SwiftUI / AppKit 进行原生开发。从 UI 细节、系统级契合度和极限性能来看，原生开发无疑是上限最高的选择。然而，在审视了现有的技术资产与工程落地效率后，我很快否定了这个选项。
-
技术栈彻底割裂，代码复用率归零
客服工作台核心的业务逻辑、网络通信协议、本地数据缓存以及复杂的实时状态控制均基于 .NET / C# 体系构建。若采用 Swift 重构，从 Socket 长连接、消息序列化到本地检索与状态管理，全部需要用 Swift 从头实现一遍，无法复用现有系统中的任何 C# 逻辑代码。
-
研发与长期维护成本成倍增加
维护两套完全独立且技术栈迥异的桌面客户端 Codebase（Windows 端 .NET + Mac 端 Swift）将带来沉重的运维负担。未来每一次业务逻辑更新、协议升级或 Bug 修复，都必须在两个生态中分别开发、测试与验证，极大地拉低了产品的迭代吞吐量。
-
双端逻辑一致性的潜在隐患
在线客服工作台包含大量的实时消息推送、访客追踪、状态同步与通知机制，细节处理极其繁琐。使用两套独立的 native 代码实现，随着版本的高频演进，极易导致 Windows 与 Mac 两端在边界条件处理和用户行为响应上出现偏差，增加故障排查与测试复杂度。
对于追求高交付效率与技术栈统一的团队而言，Mac 原生开发虽然"体验上限高"，但在商业 ROI（投入产出比）和工程可持续性上，并不是重构工作台的现实选择。
Avalonia UI ？
Avalonia UI 是目前 .NET 生态中极为优秀的跨平台 XAML 桌面框架，凭借独特的"UI 自绘"能力，能够在 Windows、macOS 和 Linux 上实现高度一致的视觉呈现。对于现有的 WPF 客服工作台来说，Avalonia 似乎是一个极为顺理成章的跨平台移植路线，它不仅能 100% 复用 C# 业务代码，连 UI 编写习惯也与 WPF 保持高度一致。
然而，在试着开发了一个简单的 DEMO 之后，我放弃了 Avalonia，主要原因在于：
-
复杂富文本与动态 UI 渲染的定制成本过高
在线客服工作台的核心场景是聊天会话区，涉及大量复杂的富文本排版、动态表情包、图片与文件拖拽预览、在 Avalonia 中，若要通过 XAML 和控件模板重头构建一套精细且高流畅度的自定义富文本渲染与交互控件，开发与调试成本极高。（Avalonia 的样式系统与 WPF 不兼容，不能直接复用）
-
Web 生态与 Web 组件难以无缝融合
现代客服工作台往往需要集成或复用已有的 Web 端资产（如后台管理系统的图表、现成的前端组件库、Web 端的富文本编辑器等）。Avalonia 虽然可以通过第三方库嵌入 WebView，但在跨平台 WebView 的深度交互、DOM 级数据通信以及样式缝合上，其体验和稳定性远不如 MAUI Blazor 这类原生将 Web 容器作为核心渲染引擎的方案。
-
社区"捧得高"与真实落地的工程巨坑
网络上充斥着大量的 Avalonia 推广文章，但绝大多数停留在跑个 Hello World 或 Demo 演示的"浅尝辄止"阶段。在我尝试实现客服工作台时，发现它在复杂布局重绘性能、高频 DOM 级交互、生态组件的健全度上，都远未达到宣扬的"完美"程度。许多看似美好的跨平台特性，在真实项目的边界条件和复杂业务下远远达不到工业级的水准。
此外，Avalonia UI 的 AI 辅助编程效果非常不好，和用 AI 辅助来进行 Web 网页制作的恐怖效率没法比。
-
商业授权与高级生态组件的潜在成本
虽然 Avalonia UI 核心框架基于 MIT 协议开源，但许多关键生态组件和高级工具已转向商业订阅模式（如包含富文本编辑器、图表等高级 UI 控件的 Pro 商业组件库）。
.NET MAUI Blazor Hybird APP
曾经很长一段时间，我以为 Blazor Hybird APP 只不过又是一个 "网页套壳" 方案，这次我仔细调查，尝试编写 Demo 之后，发现小丑竟是我自，它不是简单的"在桌面应用里嵌一个网页"，而是通过现代混合架构，完美兼顾了 .NET 后台的极致工程效率与 Web 前端的强大 UI 表现力。
我锁定了 .NET MAUI Blazor Hybrid 作为这次重构与全平台统一的终极方案。
-
进程内原生执行，无 WebAssembly/HTTP 性能损耗
与传统的 Electron 或 Blazor WebAssembly 不同，Blazor Hybrid 中的 C# 代码并非运行在浏览器沙盒或 WASM 虚拟机中，而是直接由宿主系统的 .NET 运行时（CoreCLR）在进程内以原生代码执行 。这意味着庞大的 C# 业务逻辑（如长连接通信、加解密、本地缓存）可以毫无性能折损地直接运行，并且 C# 与前端 JavaScript/DOM 之间的交互是进程内的直接内存调用，避免了频繁网络协议序列化的开销。
-
Web 技术栈赋能复杂聊天 UI，开发效率翻倍
客服工作台的核心是聊天会话区，涉及高度复杂的富文本渲染、图文混排、动态表情、拖拽上传以及卡片消息。借助 Blazor Hybrid，我可以直接使用 HTML5 与现代 CSS（Flex/Grid）构建这些高频交互界面，甚至能直接引入现成的现代前端生态与 UI 组件库。相比重头造 XAML 控件轮子，UI 迭代效率与视觉表现力得到了数量级的提升。
在这一点上，叠加 AI 辅助编程，工程效率进一步大幅度提升。
-
100% 共享 C# 领域逻辑，彻底消除"双端差异"
重构后，Windows 与 Mac 客户端共享同一套核心 .NET 类库（包括网络请求、推送协议、状态管理与数据模型）。跨平台差异被彻底收拢在最底层的 OS 硬件 API 抽象中，不仅把 C# 代码复用率拉满，也保证了 Windows 和 Mac 用户在业务功能、异常处理与消息同步上的完全一致。
-
官方第一方框架背书，零额外授权门槛
.NET MAUI Blazor Hybrid 是微软 .NET SDK 原生集成的官方第一方跨平台解决方案。它完全开源免费，没有任何商业授权限制或隐藏的付费组件订阅风险。随 .NET 最新运行时持续进化，其在 macOS 上的原生 WebView（WKWebView）对接、高分屏缩放以及系统原生 API 调用（如通知、托盘、文件系统）上都具备极高的稳定性与长期的技术安全感。
.NET MAUI Blazor Hybird APP 的初始实现效果
经过 2 个多月的重构开发，我完成了一个初步版本，实现了基本的访客跟踪和聊天功能，复用了过去 WPF 客服工作台几乎全部核心代码。（感恩过去的自己在实现 WPF 客服工作台时，UI 只处理 UI，所有业务逻辑在 UI 无关的独立类库中）。
作为对比，先看看 WPF 版本客服工作台的样子，这是一个多年积累的生产级版本：
WPF 版本
.NET MAUI Blazor Hybird APP 重构版本
目前 .NET MAUI Blazor Hybird APP 重构版本还是一个最小可用集的状态，仅实现了基本的访客追踪和聊天会话功能。接下来还需要把访客管理、历史记录管理、访客留言，以及常用文件、快捷回复这些功能从 WPF 中移植过来。好在这些功能的移植只是工作量的问题和时间问题，技术上已经没有了任何障碍。
最后还有 UI 的美化工作，这 2 个多月集中精力编码， UI 还比较简陋，在所有移植工作完成后，还需要对 UI 来一次美化调优。
重构过程中的分享
最后，说说我的一点额外感想。在使用 .NET MAUI Blazor Hybird APP 重构的过程中，为了调查和学习这方面的技术，我查遍了国内各大论坛，但是资料非常非常少！！
我使用 .NET MAUI Blazor 作为关键词检索内容，除了早几年一些布道者发布的简单介绍和 Hello World 之外，啥也没有！！！ 如果时间拉近到近一两年，连布道者和 Hello World 都没了......
但实事上经过我这 2 个多月的调查、学习、开发，我感觉到 .NET MAUI Blazor Hybird APP 非常之强大，它的理念、技术实现方法、开发效率、工程化水平，比 Electron 之类的网页套壳不知道高到哪里去了......
要总结一句话来说，就是：虽然 .NET MAUI Blazor Hybird APP 使用了 Web 技术作为 UI ，但它是正了八经 "软件开发"，不是 "做网页"。
所以我想在后续的重构移植工作中，带着记录，写一写这方面的技术实践。
小广告时间：
如果您感兴趣：
升讯威客服系统仍处于不断演进的过程中。
如果您曾经构建或部署过实时聊天系统，我非常期待与您交流心得。
- 🌐 官方网站：https://kf.shengxunwei.com
- 📘 技术文档：https://docs.shengxunwei.com
无论您倾向于使用托管版还是自行部署（Self-hosting），都可以免费使用。