应用应该做成什么平台

很多人一有想法，就先问：“该用 Flutter、Electron，还是微信小程序？”

这个顺序反了。平台不是一道技术偏好题，它取决于用户在哪里打开软件、任务发生在什么设备上，以及软件需要多深的系统权限。

比如，同样是“售后服务”：消费者入口适合放在微信小程序，客服和运营人员需要网页管理后台，维修工程师可能还要一个能拍照、扫码、离线填写的移动端。业务只有一个，入口却可以不止一个。

::: tip 先记住这句话 能用链接解决的，先做 Web；用户就在微信里，先做小程序；需要后台运行、硬件或系统权限，再考虑原生；同一业务有多种角色，就让多个客户端共用一个后端。 :::

1. 先问三个问题

用户会从哪里打开它？

• 从搜索、链接或企业门户进入：优先考虑网站或 PWA。
• 从微信群、公众号或线下二维码进入：优先考虑微信小程序。
• 每天长时间使用，窗口需要一直开着：优先考虑桌面端。
• 工作本来就在浏览器或编辑器里完成：优先考虑浏览器插件或 IDE 插件。

它需要哪些设备能力？

相机、扫码和定位不一定非要原生 App；真正拉开差距的是长时间后台运行、蓝牙和串口通信、本地大文件处理、系统级快捷键、设备驱动与严格的性能要求。

需要的权限越深，越应该靠近操作系统；只是填表、查数据、看报表，就没必要一开始承担原生开发的成本。

谁来长期维护？

“一套代码发布多个平台”可以减少重复工作，但不会消除平台差异。应用商店审核、登录、支付、通知、权限、文件系统和窗口行为，最后仍然要分别测试。

先做最重要的一个入口，确认业务有人用，再扩展第二个平台，通常比第一天就同时做五端更稳。

2. 九条常见架构路线

2.1 网站 / PWA：先让用户点开就能用

如果用户只是想打开链接完成一件事，Web 往往是第一版最省力的选择。PWA 仍然是网站，只是增加了安装到桌面、离线缓存等能力。

企业通常用它做 SaaS 后台、CRM、数据看板、知识库、在线教育、预约系统和内容网站。它最擅长公开访问、快速更新和多设备覆盖。

如果产品必须长期在后台运行，或者要深度访问蓝牙、系统文件与设备驱动，就不要硬把网页包装成原生软件。

相关教程：开发 PWA 本地应用

2.2 微信小程序：用户本来就在微信里

小程序的优势不是“比 App 高级”，而是用户不用安装。扫码、群分享、公众号和门店入口都能把用户直接带进业务流程。

企业通常用它做会员中心、门店点单、活动报名、预约、售后工单、物流查询和轻量商城。用户侧流程很短、使用频率不高时，小程序尤其合适。

它受微信运行环境和审核规则约束。需要长时间后台任务、复杂本地计算或离开微信独立运营时，应当考虑 App 或 Web。

相关教程：开发微信小程序 · 开发带后端的微信小程序

2.3 iOS / Android 原生：直接使用系统能力

原生开发离操作系统最近。后台定位、蓝牙、健康数据、音视频、复杂动画和系统级安全能力，原生通常拥有最完整的支持。

企业通常用它做运动健康、导航、金融客户端、相机与剪辑工具、车机配套应用、蓝牙设备控制和高频消费类 App。

代价也很直接：iOS 和 Android 有各自的工程、发布流程和测试成本。只有一个人做第一版，而且核心功能只是表单与列表时，原生往往太重。

相关教程：开发 iOS 应用 · 开发 Android 应用

2.4 Flutter / React Native：共享业务，分别落到两端

团队明确需要 iOS 和 Android，又不想维护两套完整业务代码时，可以选择 Flutter 或 React Native。大部分界面和业务逻辑共享，平台能力再通过插件或原生模块接入。

企业通常用它做电商、会员、销售拜访、现场服务、内部办公和内容社区。它适合“两个移动平台的业务大体相同”这种情况。

跨端不是按一下按钮就自动适配。通知、支付、地图、权限和商店发布仍然要在两端分别验证；重度 3D、复杂音视频或大量平台专属能力，也可能需要回到原生。

2.5 Electron / Tauri：用 Web 技术做桌面软件

如果团队熟悉 Vue、React 或普通前端，又需要独立窗口、托盘、文件读写和桌面通知，Electron 或 Tauri 会比从头学习原生桌面开发更快。

企业通常用它做协作客户端、AI 桌面助手、知识库、数据导入工具、客服工作台和内部运营工具。Electron 自带 Chromium 与 Node.js，生态成熟；Tauri 使用系统 WebView，并通过 Rust 等能力连接系统，安装包通常更轻。

如果软件需要极低内存、复杂图形、设备驱动或严格实时响应，仅靠 Web 桌面方案可能不合适。

相关教程：开发 Electron 桌面程序

2.6 Qt / 原生桌面端：业务软件直接连接设备与系统

Qt 不只是“工厂大屏”。在工业界和企业软件中，它常被用于设备控制台、医疗影像、汽车诊断、实验室软件、交易终端、工程设计工具和长期运行的桌面客户端。

这类软件通常需要连接串口、Modbus、CAN、仪器或本地数据库，还要在 Windows、Linux 与嵌入式设备上稳定运行。Qt 的价值在这里，不在于页面看起来像不像网页。

如果产品只是一个普通信息管理后台，Web 会更容易部署和维护；只有真的需要本地设备、离线运行或长期桌面交互时，才值得选择更重的桌面架构。

相关教程：开发 Qt 企业设备与运营客户端

2.7 浏览器插件：功能就发生在网页旁边

如果用户的工作本来就在网页里，就别再让他复制内容、打开另一个系统、粘贴并提交。浏览器插件可以直接读取当前页面，在侧边栏或右键菜单里完成下一步。

企业通常用它做网页翻译、密码填充、销售线索补全、客服知识助手、合规检查、网页数据采集和内部流程快捷入口。

插件权限很敏感。只申请真正需要的站点和能力，并把共享密钥放在企业后端；需要脱离浏览器独立运行时，插件也不是合适的容器。

相关教程：开发浏览器 AI 插件

2.8 VS Code 插件 / CLI：把工具放进开发流程

面向开发者的工具，最好出现在他们已经工作的地方。需要读取当前文件、展示诊断和提供编辑器交互时做 VS Code 插件；需要进入脚本、CI 和批处理流程时做 CLI。

企业通常用它做代码规范、依赖升级、项目脚手架、发布检查、数据库迁移、内部平台接入和 AI 编程助手。很多工具最后会同时提供插件和 CLI：一个负责交互，一个负责自动化。

相关教程：开发 VS Code 插件

2.9 多端企业系统：不同角色使用不同入口

企业业务很少永远停在单个平台。消费者、现场员工、运营人员和管理者的工作环境不同，强迫所有人使用同一种客户端，体验通常会很差。

常见组合是：小程序服务消费者，移动端服务现场人员，Web 后台服务运营，桌面端连接本地文件或设备；下面共用统一身份、业务 API、数据库、文件存储和审计日志。

这里真正需要共享的是业务规则和数据，不是强求每个端的界面代码完全相同。第一版仍然应该只做最关键的入口，后端边界稳定后再扩展其他客户端。

3. 一张表先选出第一版

4. 企业里通常怎么组合

零售与会员服务

消费者用微信小程序查积分、领券和申请售后；店员用移动端核销；总部在 Web 后台配置活动和看数据。三个入口共用会员、订单和权限系统。

现场服务与售后

客户从小程序报修，工程师在移动端接单、拍照和离线记录，调度人员在 Web 后台安排任务。如果还要连接检测仪器，再给工程师增加 Qt 或原生桌面工具。

企业知识与 AI 助手

知识库和权限放在企业后端。员工在浏览器里工作，就提供侧边栏插件；在 VS Code 中工作，就提供 IDE 插件；需要批量处理时，再提供 CLI。

设备、医疗与工程软件

本地 Qt 或原生客户端负责设备通信、实时数据和安全操作，Web 平台负责远程配置、报表与管理。这里是工业界常见的软件组合，但它只是企业软件的一部分，不代表所有企业系统都需要 Qt。

5. 决策时按这个顺序走

如果几个答案同时成立，不必硬选唯一平台。先确定最重要的用户和最频繁的任务，把第一条完整链路做通，再决定第二个入口。

6. 几个常见误区

“一套代码”不等于“一次测试”

跨端框架能共享代码，但不能替你完成权限、支付、通知、窗口、应用商店和真机兼容测试。选跨端是为了减少重复，不是消灭平台差异。

企业软件不等于工控软件

CRM、审批、排班、售后、知识库和零售会员都属于企业使用场景。只有真的连接设备、协议、实时数据或本地大文件时，Qt 与原生桌面端才会自然地成为优先选项。

不要第一天就做全平台

同时做 Web、小程序、iOS、Android 和桌面端，很容易得到五个都不完整的版本。先选一个最短入口验证业务，再扩展其他端。

客户端不同，后端仍应当统一

多端产品最怕每个客户端各写一套会员、订单和权限规则。界面可以不同，核心身份、业务规则、数据与审计应该从同一套后端提供。

7. 接下来选一篇开始做

参考资料

• Apple SwiftUI 官方文档
• Android 应用架构指南
• PWA 官方学习指南
• Flutter 官方介绍
• React Native 官方入门
• Electron 进程模型
• Tauri 架构
• Qt 官方介绍
• Chrome 扩展开发文档
• VS Code Extension Host