PWA、小程序还是原生：2026 选型框架

错误的问题

团队仍在问"我们该建应用还是网站？"这个框架已经过时。2026 年，你在三种交付单元之间选择——渐进式 Web 应用、原生应用、受控小程序——而正确答案取决于你的约束，而非流行。

决策维度

维度	PWA	原生应用	受控小程序
触达 / 发现	仅靠链接；安装意愿弱	应用商店；强但竞争激烈	在每日高频的宿主之内
上市速度	快（Web 栈）	慢（按店构建 + 审核）	快（沙箱，轻审核）
分发控制权	你拥有链接	商店拥有门槛	宿主拥有界面
身份与支付	按市场重写	按市场重写	从宿主继承
合规姿态	难以自证	由你认证	审计沙箱，可证明
离线能力	有限	完整	取决于宿主
跨宿主可移植性	高（Web）	无（锁死商店）	高（开放运行时）

经验法则

用 PWA，当任务是快速、可链接分享、低参与的 Web 体验——一个营销流程、一份文档、一次性交互。它是被触达成本最低的方式，而非拥有一段关系的方式。

用 原生应用，当你需要深层设备能力（蓝牙、后台同步、重度离线、AR），或你正在构建核心产品、且能赢下主屏位置与应用商店的投入。原生是"产品即公司"时的正确单元。

用 受控小程序，当你需要触达一个信任的用户在他已在打开的宿主之内，尤其当市场受监管、多币种或多语言时。它继承身份、支付与同意，即时上线，并通过电信、银行或市场真正会批准的合规门槛。

大多数团队忽略的规律

三者并非互斥——它们是层。原生应用可以承载小程序；PWA 可以是把流量交给更深体验的顶层漏斗。错误在于把单一单元当作整盘策略。让单元匹配用户旅程中那个时刻的工作，再用一个开放运行时把受控程序带到各个宿主，你就无需为每个封闭花园重写。

简单的分诊

你需要深层设备 API，或这是核心产品吗？ → 原生。
这是轻量、靠链接驱动、低承诺的交互吗？ → PWA。
你需要在不拥有的宿主之内，跨市场获得信任、支付与合规吗？ → 受控小程序。

如果你对第 3 点答"是"——而多数分发、电商与服务工作正是如此——受控小程序就是你的单元。

Cross Mini App 的位置

Cross Mini App 是让第三种选择在规模上成立的运行时与开放目录。你构建一次受控小程序，就能分发到无数受信任的宿主——钱包、地图应用、超级 App、市场——继承身份、支付与同意，而非重写它们。这些体验预先合规、受沙箱保护、本地化，在用户已在信任的界面上触达他们，且无需任何按店、按花园的重写。按工作选单元；让开放的跨 App 运行时把它带到各处。

按约束决策，而非按 hype

2026 年的答案很少是"应用 vs 网站"。它是"哪个单元适配此刻的工作，我又如何让它跨宿主而不重写？"想清楚这一点，分发就不再是赌注，而成为一套系统。