01 — 核心架构概述 ​

1. 一句话定位 ​

Taro 是 「一套业务代码 + 多端适配层」 的跨端方案：业务侧主要写 React / Vue3 / Solid 等框架代码；编译期 通过 Webpack5 或 Vite 把模块图打出来；小程序端 再辅以 模板（wxml 等）+ 自定义运行时（类 DOM + setData） 把框架渲染接到各小程序宿主上。

这与 Taro 1/2 时代「把代码编译成小程序语法树」的路线不同，Taro 3 起核心是 运行时适配（官方博客有专门阐述，见文末链接）。

2. 三层结构（建议画图梳理） ​

flowchart TB
  subgraph dev [开发层]
    FW[React / Vue3 / Solid]
    API[@tarojs/taro API]
  end
  subgraph compile [编译层]
    CLI[taro-cli + Kernel 插件]
    Runner[webpack5-runner / vite-runner]
    Babel[Babel preset / 插件]
    PostCSS[PostCSS 链]
    MiniPlugin[MiniPlugin 等 Webpack 插件]
  end
  subgraph runtime [运行时层]
    TR[@tarojs/runtime 类 DOM]
    Rec[框架 Reconciler]
    Plat[@tarojs/platform-* hostConfig / 模板]
  end
  FW --> Babel
  API --> Babel
  Babel --> Runner
  PostCSS --> Runner
  CLI --> Runner
  Runner --> MiniPlugin
  MiniPlugin --> Plat
  Rec --> TR
  Plat --> TR

3. CLI 内核：Kernel 与插件 ​

taro-service 里的 Kernel 负责 预设（preset）与插件（plugin）的解析、注册、生命周期，是 Taro CLI 的「小型插件系统」。

典型初始化包括：合并 CLI 与项目里的 presets/plugins、对插件路径做 swc register（便于用 TS 写插件）、维护 hooks / methods / platforms 等。

入口阅读建议：packages/taro-service/src/Kernel.ts（initPresetsAndPlugins 一段即可建立心智模型）。

4. 平台抽象：TaroPlatform 与 Runner 选择 ​

TaroPlatform 抽象里明确了 合法编译器只有 webpack5 与 vite，其余值会回退到默认 webpack5，保证旧配置兼容：

const VALID_COMPILER = ['webpack5', 'vite']
const DEFAULT_COMPILER = 'webpack5'
// ...
    const _compiler = config.compiler
    this.compiler = typeof _compiler === 'object' ? _compiler.type : _compiler
    // Note: 兼容 webpack4 和不填写 compiler 的情况，默认使用 webpack5
    if (!VALID_COMPILER.includes(this.compiler)) {
      this.compiler = DEFAULT_COMPILER
    }

具体 拉起 Runner 的逻辑在 packages/taro-service/src/platform-plugin-base/mini.ts / web.ts：compiler === 'vite' 时用 @tarojs/vite-runner，否则 @tarojs/webpack5-runner。

5. 多端在仓库里的落点 ​

6. 小结（表述话术） ​

• 不是「把 React 编译成 wxml」一条线到底；而是 Babel/ bundler 处理 JS 模块 + 小程序侧用模板表达渲染结构 + Runtime 把框架树变成数据并 setData。
• 平台差异 尽量收敛在 platform-*（模板 Adapter、hostConfig 钩子）与 shared 的模板生成逻辑，而不是散落在业务里。

延伸阅读 ​

• Taro 官方文档 - 指南
• Taro 3 相关博客索引