多平台的分叉税
几年前，小程序模式几乎只在微信里存在。如今它已蔓延到支付宝、抖音，以及一波国际化平台——Telegram、WhatsApp 和各地超级 App 都在搭建自己的小程序能力。这对触达是好事，对任何维护代码的人却是坏消息：每个平台都保留自己的技术要求、工具链和政策。为每个平台做原生开发，你拥有的不是「一个应用」，而是 N 个应用，每次发版都彼此偏离一点。
WebView 捷径也救不了你。把一个网页塞进每个宿主的 WebView 看似可移植，可一旦你需要宿主的身份、支付或定位，你还是得为每个宿主重新接原生桥、登录握手和审核流程。你躲开了一个分叉，却继承了三套集成。
一个表面，多个宿主
小程序运行时把模型反转了。你不再为每个平台改造代码，而是针对统一的 API 表面——大家熟悉的 wx.* 家族——写一次，由运行时把这些调用映射到宿主提供的任何能力。跨平台 SDK 厂商描述的正好如此：一个抽象层把标准化代码翻译成平台特定的实现，于是开发者只需专注应用逻辑，而非平台适配。
阿里 mPaaS 把价值说得很直白——一次开发、多端部署，用同一套代码把一个小程序分发到钉钉、淘宝和支付宝。FinClip 在宿主侧给出同样的承诺：嵌入一个轻量 SDK，你既有的 App 不必重构就成为小程序平台。吸收逐宿主差异的是运行时，不是你的团队。
为什么这对开放 catalog 重要
对于一个由已验证小程序组成的 catalog——也就是把国内经过验证的小程序带到海外 App 的 crossminiapp 论点——可移植性就是整个商业逻辑。写一次的程式应当落到任何装了运行时的宿主上，就像网页落到任何浏览器里。正是这一点，把一次性的移植项目变成可复用的库。
它也改变了合规的算法。当运行时经手每一次特权调用、平台在每次提交时审核，向伙伴开放 App 就变成一项受治理、可重复的操作，而非每个合作方一次性的安全评估。
成本，逐项对照
| 维度 | 逐平台分叉 | 通用运行时 |
|---|---|---|
| 需维护的代码库 | 每宿主一套 | 一套 |
| 原生能力访问 | 逐宿主重接 | 统一 wx.* 表面 |
| 更新节奏 | 绑死各宿主流水线 | 解耦，运行时可控 |
| 合规面 | 逐集成审核 | 集中提交审核 |
| 触达 | 每加一个宿主成本上升 | 触达上升，成本不升 |
分叉模型对你新增的每一个宿主征税；运行时模型一个都不征——你为写程式付一次钱，再为认证它上新的宿主轻量付一次。
Cross Mini App 如何落地
Cross Mini App 是作为通用运行时来构建的：一个 wx.* API 表面，能力门控、提交时审核，让同一个小程序在每个嵌入它的宿主上运行。一个被验证过的程式变成可移植资产——写一次，发到多个 App，其余交给运行时。
这就是逐平台分叉与真正的 catalog 之间的区别：分叉成倍放大你的工作量；运行时成倍放大你的触达。
