你不知道的客户端开发：AI 时代下的选型、原生与借力
内容提要
文章讨论客户端开发的Web、跨端与原生三条路径，分析研发效率、体验、性能构成的“不可能三角”，认为AI降低原生开发成本后，应用类场景更值得选原生。作者以Mole Windows为例，介绍用C#、WinUI 3和.NET 10开发，在Mac上通过虚拟机和脚本完成编译测试，复用设计、文案和规则而非代码，并分享Windows签名、测试及跨语言调用补短板的经验。
延伸解读
“不可能三角”下的选型逻辑
文章将客户端开发归纳为Web、跨端、原生三条路径，并指出研发效率、体验、性能构成“不可能三角”。Web偏效率、原生偏性能体验、跨端取中间值。作者认为AI降低了原生开发成本，补上了效率短板，因此应用类场景更值得选原生；但跨端在业务效果优先、工作量极大时仍是合理选择。选型应回到场景本身，而非技术偏好。
代码难复用，规则才是复用层
作者尝试复用Mac版Swift代码时发现，十几万行中能脱离系统框架使用的不足20%，Windows版几乎从零写起。真正可复用的是设计token、多语言文案和踩坑后沉淀的规则，并通过脚本同步、记录对应提交、用SYNC.md对账来防止两边走偏。这提示跨平台开发中，抽象规则比抽象代码更可持续，也更适合交给AI执行。
Windows分发的隐性成本
文章详细记录了Windows签名的麻烦：未签名会触发SmartScreen拦截甚至被安全软件报毒；微软Azure Artifact Signing个人仅限美加开发者；2023年起私钥须放硬件或云端HSM，证书有效期最长460天。作者购买Certum云端OV证书，并持续向微软提交安装包积累信誉。这说明Windows分发的门槛不在写代码，而在证书、信誉和人工验证流程。
架构分层让Mac成为开发主场
Mole Windows分为四层：Core只依赖.NET、不碰Windows接口，可在Mac上测试；Platform层封装注册表和Win32调用；ViewModel层与Mac版一一对应；只有WinUI界面层必须在Windows编译。配合Parallels共享文件夹和脚本执行，作者一个月写出8万多行代码和4000多个测试。其价值在于把平台相关代码压到最薄，使大部分逻辑能在熟悉环境中验证。
Q&A
客户端开发一般有哪几条技术路线？各自有什么特点？
文章指出客户端开发主要有三条路线：1）Web 路线，将网页塞进浏览器或原生壳（如 PhoneGap、Cordova），开发简单但性能较差；2）跨端路线，一份代码多端运行（如 React Native、Flutter、Electron、Tauri），追求效率与性能的平衡，但可能牺牲一致性或包体积；3）原生路线，使用平台官方语言和框架（如 Swift、Kotlin、C#），性能和体验最好，但开发成本高。
什么是客户端开发的“不可能三角”？
文章提出研发效率、体验、性能构成一个“不可能三角”。选择 Web 是多效率少性能；选原生是多性能体验少效率；选跨端则是三者取中间，做得好容易都占，做得不好可能一边都占不到。
AI 时代为什么更推荐应用类场景选择原生开发？
因为 AI 大幅降低了编写两份原生代码的成本，补上了“效率”这一边，让原生开发在保持高性能、好体验、低内存占用的同时，效率不再是大问题。对于需要调用系统底层能力、操作更顺手、分发更直接的应用场景，原生技术能第一时间享受系统官方调优和最原生的交互效果。
Mole Windows 版用了什么技术栈？为什么选择它？
Mole Windows 版使用 C# + WinUI 3，运行在 .NET 10 上。选择原因是 WinUI 3 是微软主推的原生界面框架，基础组件为 Windows 11 Fluent 风格，支持高分屏缩放和 ARM64，且普通 Win32 程序也能用；.NET 10 是长期支持版本，打包时自带运行时，用户无需额外安装。
在 Mac 上开发 Windows 软件，如何搭建开发和测试环境？
作者在 Mac 上使用 Parallels Desktop 安装 Windows 11 虚拟机，将代码仓库作为共享文件夹挂载为 X 盘，Mac 上改代码，虚拟机内直接编译。编译、启动、看日志等工作写成脚本，通过 prlctl exec 在虚拟机执行；程序崩溃时脚本会打印 Mole 写入的异常日志供 AI 读取。另外准备了一台 ThinkPad X1 Carbon 作为真机环境，通过 UU 远程和 SSH 从 Mac 操作，进行真实环境测试。
Mole Windows 的架构分层是怎样的？这样设计有什么好处？
架构分为四层：最底层 Core 只依赖 .NET，不碰 Windows 接口，包含清理规则、路径安全检查等，测试用模拟内存文件系统，可在 Mac 上跑；Platform 层封装注册表、文件系统、Win32 调用等系统接口，开启 EnableWindowsTargeting 后 Mac 上也能编译；ViewModel 层与 Mac 版一一对应，可在 Mac 上测试；最上层 WinUI 界面必须在 Windows 中编译。好处是大部分代码和测试可在 Mac 上完成，作者一个月写了 8 万多行代码和 4000 多个测试。
Windows 应用签名为什么比 Mac 麻烦？作者是如何解决的？
Windows 未签名应用会触发 SmartScreen 警告甚至被智能应用控制阻止，国内安全软件也可能报毒。微软签名生态限制多：Azure Artifact Signing 个人仅限美加开发者；2023 年起私钥必须放在硬件或云端 HSM；2025 年起单张证书最长 460 天。作者购买了 Certum 云端 OV 证书（3 年 300 多美元），签名时登录 SimplySign 并用手机动态码验证，同时每次发版将安装包提交微软恶意软件分析门户以积累 SmartScreen 信誉。
在客户端开发中如何借其他语言的生态补短板？能举例说明吗？
文章举例：在 Swift 开发的 Markdown 笔记应用妙言中，通过 JavaScriptCore 调用 JS 实现复杂的 Markdown 格式化；在 Rust 开发的 Pake 中，通过 Rust 调用 JS 渲染 Toast 通知，反向也可让 JS 调用 Rust 的下载能力；在妙言分栏编辑中，用 C 语言库 cmark-gfm 解析 Markdown，JS 读取行标记后通过消息通道通知 Swift 同步滚动；在 Kaku 中利用终端转义序列将自然语言传给 Lua，再交 Rust 请求模型生成命令回填。核心思路是把不同语言当工具，按场景选择最合适的语言。
