🟢 小程序生态

一句话定性

小程序是跨端史里中国独有的一个分支物种。它不是技术社区自下而上长出来的,而是超级 App 自上而下定义的——平台说”你要在我的地盘上做应用,就得用我规定的双线程模型、受限 WebView 和私有 DSL”。它长得像前端,却不是标准 Web。这条线与 Vue/React 在中国的流行深度纠缠,也催生了”一套语法编译到多端”的 Taro/uni-app。

一、它是什么 & 出现的时代

2017 年 1 月,微信上线小程序:一种无需安装、扫码即用、用完即走的轻应用,运行在微信 App 内部。随后形成了一个生态:

平台	宿主 App	上线
微信小程序	微信	2017
支付宝小程序	支付宝	2018
抖音 / 头条小程序	字节系	2018+
百度智能小程序、快应用…	各超级 App	2018+

它的形态似前端而非标准 Web:你写的是微信定义的私有 DSL——

<!-- index.wxml(类 HTML,但是私有标签) -->
<view class="card">
  <text>{{ msg }}</text>
  <button bindtap="onTap">点我</button>
</view>

/* index.wxss(类 CSS,带 rpx 等私有单位) */
.card { padding: 20rpx; }

这是跨端与全栈演进史横向扩张里最特殊的一站

移动端(RN)和桌面端(Electron)是前端主动向外扩张;而小程序是平台反向定义了一种”类前端但受管控”的开发形态——前端是被请进一个有围墙的花园里干活的。

二、为什么会出现(解决上一代什么痛点)

小程序解决的不是开发者的技术痛点,而是平台方和用户的痛点——这是理解它的钥匙。

原生 App 与 H5 的双重困境(在中国语境下)

原生 App 太重:用户为一个低频服务(点餐、缴费、查询)装一个几十兆的 App,装完用一次就卸载。获客成本极高。

H5 体验太差、能力受限:微信内置浏览器里的 H5 页面,性能差、能力弱、还不可信(钓鱼链接泛滥)。

平台想留住流量:跳出微信去外部网页 = 流量流失 + 风险不可控。

为什么偏偏在中国爆发?三个中国特有的结构性条件

超级 App 即入口:微信/支付宝是国民级超级 App,几乎人人安装、长时在线。它们有能力、也有动机把自己变成一个应用分发平台/操作系统——小程序就是它们的”App Store”。

即用即走的用户习惯 + 监管/分发约束:在国内,iOS 受 App Store 审核与抽成约束、安卓商店极度分散。小程序提供了一条绕过原生分发、由超级 App 统一审核分发的通道,扫码/搜索/分享即可触达,完美契合”用完即走”。

商业闭环:微信支付、社交关系链、公众号导流——小程序天然嵌入一个完整的交易与传播闭环,商家有强动机入驻。

第一性原理看:小程序不是”更好的前端框架”,而是”超级 App 把自己变成 OS”的产物。 它的所有技术选择,都服务于平台的管控诉求,而非开发者的体验。

三、核心机制 & 为什么流行

双线程模型:为什么小程序长这样
普通网页是单线程(JS 和渲染抢同一个主线程,且 JS 能随意操作 DOM)。小程序刻意把它拆成双线程:
  逻辑层(AppService)            渲染层(WebView, 受限)
  ─────────────────             ──────────────────────
  你的 JS 业务逻辑      ◄──┐      WXML/WXSS 渲染界面
  在独立 JS 引擎跑          │      运行在受管控的 WebView
       │                   │           ▲
       └── setData ────────┴───────────┘
           (跨线程通信, 不能直接操作 DOM)
为什么这么设计? 两个平台诉求:

安全管控:逻辑层拿不到 DOM、拿不到完整的浏览器 API,开发者无法逃逸出平台的沙箱(防止跳转外链、防止滥用能力)。

性能隔离:逻辑与渲染分离,JS 计算不直接阻塞渲染。

代价是:数据更新必须通过 setData 跨线程传递,频繁/大数据量 setData 成为小程序最经典的性能坑——这是双线程架构的抽象泄漏。

与前端框架的纠缠:小程序的 DSL 设计明显借鉴了当时正流行的框架——{{ }} 插值和 wx:for 像 Vue 的模板,组件化思想来自 React/Vue。正因为它”长得像前端”,会 Vue/React 的人能快速上手,这反过来又强化了 Vue 在中国的统治地位(详见为什么Vue在中国崛起)。

为什么流行 / 跨小程序框架的诞生

小程序生态一旦碎片化(微信、支付宝、抖音各一套 DSL,语法互不兼容),开发者就要写 N 遍——这正是跨端母题的又一次重演。于是诞生了跨小程序编译框架:

框架	出身	思路
Taro(京东)	类 React 语法	用 React/JSX 写一遍,编译到微信/支付宝/抖音小程序 + H5 + RN
uni-app(DCloud)	类 Vue 语法	用 Vue 写一遍,编译到各家小程序 + H5 + App

又一次"一套语法,编译多端"

Taro/uni-app 把”复用技能、一码多端”的母题推到极致:你用熟悉的 React/Vue 语法写,编译器负责把它翻译成每家平台的私有 DSL。 这和 RN 的”learn once write anywhere”、和 Babel 把新语法编译到旧环境,是同一种工程哲学——用一层编译抽象,抹平下游的碎片化。

四、带来的新问题 / 副作用

围墙花园的代价

平台锁定(vendor lock-in):你的代码、用户、数据都长在别人的平台里。平台改规则、降权、封禁,开发者毫无还手之力。

非标准 Web,技能不完全通用:WXML/WXSS/rpx/双线程模型都是私有的,学到的东西只在这个平台值钱,无法迁移到标准 Web。

setData 性能陷阱:双线程通信开销让复杂小程序的性能优化成为专门学问。

跨端框架的”漏斗”问题:Taro/uni-app 抹平了多数差异,但各平台的能力差异、bug 总会从抽象层漏出来,最后还是要写平台特定代码(“一码多端”在边角处变成”一码多端 + 各端补丁”)。

生态割裂:小程序生态与标准 npm 生态部分隔绝,很多 Web 库无法直接使用。

五、为什么会衰落 / 现状

小程序在中国远未衰落,已成为基础设施——它就是中国移动互联网的”轻应用层”。现状特征:

微信小程序一家独大,支付宝/抖音小程序在各自场景稳固,形成几大割据生态。
跨端框架成熟:Taro / uni-app 成为多端团队的标配,uni-app 的 Vue 路线尤其受中国团队欢迎。
与原生 App 互补共存:高频核心业务做原生 App,中低频/引流/交易场景做小程序,已成行业默认分工。
几乎纯中国现象:海外几乎没有对应物种(海外的对应思路是 PWA,但市场逻辑完全不同)——这再次印证它是特定市场结构的产物,而非纯技术演进的产物。

六、对后续技术的影响(因果链)

中国市场:原生App太重(获客贵) + H5体验差不可信 + 超级App想做分发平台
        │
        ↓
微信小程序(2017):双线程 + 受限WebView + 私有DSL(WXML/WXSS)
        │  设计目标 = 平台管控 + 用完即走, 而非开发者体验
        │
        ├─► 借鉴 Vue/React 模板与组件化 ──► 强化 [[Vue]] 在中国流行 [[为什么Vue在中国崛起]]
        │
        ├─► 双线程通信 ──► setData 性能陷阱(抽象泄漏)
        │
        ├─► 多平台 DSL 碎片化(微信/支付宝/抖音各一套)
        │       │
        │       ↓
        │   跨小程序框架:Taro(类React) / uni-app(类Vue)
        │       └─► "一套语法编译多端" ── 与 RN 同一种工程哲学
        │
        └─► 围墙花园 ──► 平台锁定 + 技能不通用 + 生态割裂
                │
                ↓
        中国独有的"轻应用层"基础设施, 与原生App长期互补共存

历史地位

小程序是跨端母题在中国特殊市场结构下长出的独特分支:它证明了”前端形态”可以由平台权力而非技术社区来定义。它与 RN、Electron 共同构成前端横向扩张的三大方向,但又最特殊——别处的跨端是开发者翻墙出去,小程序是开发者被请进墙里。 理解它,必须先理解中国互联网的入口之争。

前端技术演化史

探索

小程序生态

🟢 小程序生态

一、它是什么 & 出现的时代

二、为什么会出现(解决上一代什么痛点)

三、核心机制 & 为什么流行

为什么流行 / 跨小程序框架的诞生

四、带来的新问题 / 副作用

五、为什么会衰落 / 现状

六、对后续技术的影响(因果链)

关系图谱

目录

反向链接