ArkTS 原生小程序 vs Taro Harmony 跨端开发深度对比 2026

当一个已经跑在微信、支付宝、抖音里的小程序团队决定进入 HarmonyOS，最容易被问偏的问题就是：「ArkTS 原生小程序和 Taro Harmony 哪个好？」本文把这个含混问题拆成可决策的工程问题：你要的是在鸿蒙生态里做一个独立应用/元服务，还是尽量复用存量小程序业务代码？

术语先校准：严格来说，ArkTS 不是「微信式小程序语言」，而是 HarmonyOS 官方应用开发语言；原生 ArkTS 路线的产物是 HarmonyOS 应用或元服务。标题中的「ArkTS 原生小程序」是团队口语 shorthand，指「为 HarmonyOS 原生生态重建小程序业务」的 ArkTS/ArkUI 路线。Taro Harmony 则指通过 Taro Harmony-CPP 插件，把小程序风格的 Taro 项目编译为鸿蒙应用。

本文只采用能从华为 HarmonyOS 官方文档、AppGallery Connect 官方帮助中心与 Taro 官方文档直接核实的事实；没有官方来源支撑的具体版本号、包体上限和性能百分比一律不写。所有「建议」都基于工程结构推导，不能替代你自己的真机压测。

一、为什么 2026 年这个问题仍然难选#

鸿蒙适配有两条完全不同的路径，很多团队把它们混在一起讨论：

1. 继续运行在鸿蒙版超级 App 内：微信、支付宝、抖音等宿主在 HarmonyOS 设备上提供运行环境，小程序仍然按各平台差异适配。这条路不需要把业务重写成 ArkTS。
2. 成为独立 HarmonyOS 应用或元服务：业务脱离超级 App 分发，需要面对 Stage 模型、ArkTS/ArkUI、签名、AppGallery 发布与多设备能力。这时才会在「原生 ArkTS」和「Taro 编译鸿蒙」之间做选择。

Taro 的价值在第二条路径里非常明确：保留 React/Vue、组件和大部分小程序 API 心智，把已有 Taro 项目编译成鸿蒙应用。原生 ArkTS 的价值也同样明确：完全进入 HarmonyOS 应用模型，直接使用 ArkUI、Ability、系统 Kit 与 ArkTS 并发能力，减少跨端映射层带来的适配面。

因此，选型不是「谁技术更先进」，而是回答四个问题：

• 存量代码资产主要是什么：Taro 小程序、原生小程序，还是服务端驱动页面？
• 鸿蒙版是战略主入口，还是渠道补充？
• 团队是否能接受 ArkTS 对 TypeScript 动态特性的约束？
• 你要用的 HarmonyOS 能力是否必须有原生页面/组件/线程模型参与？

二、技术栈对照：同在 HarmonyOS 生态，抽象层完全不同#

2.1 原生路线的真实优势#

华为官方对 ArkTS 的定位是 HarmonyOS 应用开发的官方高级语言。它在 TypeScript 生态基础上扩展，强化静态检查与分析，并通过规范定义提升健壮性、执行稳定性和性能。ArkTS 常用库与容器库补足基础能力，ArkCompiler 工具链会把 ArkTS/TS/JS 编译为 Ark 字节码 *.abc，由设备端 ArkTS Runtime 执行。

这带来的工程优势是：

• 语言与系统模型一致：页面、组件、Ability、权限、生命周期都使用同一套官方模型。
• 性能边界更清楚：没有跨端 API 映射层和公共依赖库版本选择带来的额外变量。
• 并发能力明确：官方 ArkTS 并发能力包含 TaskPool 与 Worker，并提供 Sendable 支持并发实例间对象引用传递。
• 新能力接入路径短：系统 Kit、ArkUI 能力更新后，原生工程通常能第一时间按官方 API 接入。

代价是团队要真正学习 HarmonyOS 应用开发，不是「会 TypeScript 就自动会 ArkTS」。ArkTS 为了运行性能和静态优化，禁用或限制了一批 TypeScript 特性。

2.2 Taro 路线的真实优势#

Taro 官方文档对 Harmony 支持的描述很直接：借助 Taro 可以快速开发鸿蒙应用，把小程序快速转换为鸿蒙应用。其 Harmony-CPP 插件负责安装、构建和鸿蒙工程对接：

npm i @tarojs/plugin-platform-harmony-cpp

import os from 'os'
import path from 'path'

const config = {
  // ...
  plugin: ['@tarojs/plugin-platform-harmony-cpp'],
  harmony: {
    // 官方文档：当前仅支持 Vite 编译鸿蒙应用
    compiler: 'vite',
    projectPath: path.join(os.homedir(), 'projects/my-business-project'),
    hapName: 'entry',
  },
  // ...
}

export default config

构建命令：

taro build --type harmony_cpp
taro build native-components --type harmony_cpp

这条路的优势在于：

• 复用业务资产：路由、请求层、状态管理、组件拆分、营销活动页可以保留小程序/Taro 心智。
• 保留团队技术栈：React/Vue 开发者不需要立即把所有页面改写为 ArkTS。
• 跨端仍然成立：一套代码继续服务微信/支付宝/抖音，鸿蒙作为新增编译目标。
• 原生逃生门明确：Taro 支持在页面配置中通过 usingComponents 引入鸿蒙原生组件，也可以用 importNativeComponent 引入 Taro 构建的鸿蒙原生组件；未实现 API 可监听 __taroNotSupport 自定义实现。

代价是你仍然要理解鸿蒙工程：projectPath、hapName、Stage 模型、签名与 DevEco 工具链都不会因为使用 Taro 而消失。

三、性能与包体：不要用想象百分比决策#

很多选型文章会给出「跨端性能损失 X%」「包体增加 YKB」的数字。除非你的页面、数据量、组件树和目标设备与测试完全一致，这些数字几乎没有迁移价值。更可靠的方法是比较结构性成本，再自己建立基线。

3.1 性能结构差异#

Taro 官方文档特别提醒：DevEco Studio Previewer 主要用于 ArkTS 侧 @Component UI 样式预览，在 Taro For Harmony 开发中无法使用；没有真机时推荐模拟器调试，但模拟器无法使用 IDE Profiler 测量性能。因此，不要用 Previewer 截图或模拟器体感来判断 Taro Harmony 性能。

3.2 包体结构差异#

原生 ArkTS 工程的包体取决于模块拆分、资源、系统 Kit 依赖与 ArkTS 代码规模。Taro 工程除了业务代码外，还会引入 Taro 运行时、适配层与插件管理的公共依赖库。官方文档说明该插件默认使用内置版本公共依赖库，可通过 useChoreLibrary 禁用或指定版本依赖，也能通过 ohPackage.dependencies 或鸿蒙工程 oh-package.json5 覆盖。

这意味着包体治理动作不同：

• 原生 ArkTS：治理模块数量、资源压缩、ArkTS 代码、动态加载与多设备 HAP 拆分。
• Taro Harmony：在上述基础上继续治理 Taro 运行时、公共依赖库版本、按端条件编译、未使用组件和 polyfill。

发布格式上，AppGallery Connect 官方 FAQ 明确：HAP 用于本地调试，APP 包用于应用发布；一个 APP 包可包含多个 HAP 以支持不同设备类型。真机安装 HAP 需要签名；APP 包不能本地安装。上传后，AppGallery Connect 会拆分包并重新签名 HAP。做包体对比时应统一口径：比较相同业务模块的 HAP 明细与最终上传 APP 产物，而不是拿调试 HAP 和发布 APP 混比。

3.3 必须建立的测量基线#

无论选哪条路线，技术评审至少要有以下数据：

1. 冷启动到首页可交互时间；
2. 首屏数据请求、渲染、图片加载瀑布；
3. 长列表滚动帧率与掉帧分布；
4. 高频输入/搜索/筛选的响应延迟；
5. 动画、手势、地图、视频、直播等重场景资源占用；
6. 调试 HAP 与发布 APP 的包体构成；
7. 低端 HarmonyOS 设备与目标真机的对比。

如果这些指标没有基线，讨论「原生更快」或「跨端更省」只是偏好，不是决策。

四、生态与组件库：别只看组件数量#

4.1 原生 ArkTS / ArkUI 生态#

原生路线的核心生态来自三部分：

• ArkUI 组件体系：声明式 UI、自定义组件、布局、绘制、媒体、容器等系统能力；
• HarmonyOS Kit 与系统能力：账号、支付、推送、媒体、图形、AI、分布式、安全等按业务需要接入；
• ArkTS 常用库与容器库：官方文档列出高精度浮点、二进制缓冲区、XML 生成解析转换等能力，以及多类容器库。

这带来的好处是能力边界清晰、官方文档一致。风险是已有 Web/React/Vue 组件不能直接搬运，团队需要重新建立设计系统、组件封装和测试习惯。

4.2 Taro 生态#

Taro 路线的核心生态是小程序跨端生态：

• React/Vue 语法与状态管理库；
• Taro 组件与 API；
• 存量业务组件、营销组件、请求封装；
• 第三方小程序组件库中支持 Taro 的部分；
• 鸿蒙原生组件作为局部增强。

官方文档提供了两条集成路径：

/** index.config.ts */
export default {
  usingComponents: {
    title: './path/to/title-component',
  },
}

/** index.tsx */
import { View } from '@tarojs/components'

export default function Index() {
  return (
    <View>
      <title title="Hello World!" />
    </View>
  )
}

如果组件需要类型提示，可以构建鸿蒙原生组件并用 importNativeComponent 引入：

/** title.ts */
import { View } from '@tarojs/components'

definePageConfig({
  entryOption: false,
  componentName: 'Title',
})

export default function Title({ title = 'Hello World' }) {
  return <View>{title}</View>
}

export const Title = importNativeComponent<typeof import('./title').default>(
  './title',
  'title',
  'Title',
)

这条逃生门很重要：Taro 不要求整个应用一次性原生化。你可以让大部分页面继续使用 Taro 组件，把地图、相机、蓝牙、动画、复杂列表等少数页面换成鸿蒙原生组件。

4.3 组件库评估表#

评估组件库时，不要问「有没有组件」，而要按以下清单验收：

五、迁移成本：原生不是重写一切，跨端也不是零成本#

5.1 ArkTS 迁移的真实成本#

华为官方《从 TypeScript 到 ArkTS 的适配规则》明确说明：ArkTS 约束 TypeScript 中影响开发正确性或增加运行时开销的特性，重构后的代码仍是合法有效的 TypeScript 代码。文档列出的典型限制包括：

• 强制静态类型，禁止 any；
• 禁止运行时改变对象布局，例如动态添加/删除属性或方法；
• 不支持 structural typing；
• 使用 let 而非 var；
• 使用具体类型而非 any 或 unknown；
• 使用 class 替代若干函数/构造签名的类型表达方式；
• 不支持 index signature；
• 不支持解构赋值/解构变量声明；
• 不支持 delete；
• 不支持 globalThis；
• 不支持 Function.apply、Function.call、Function.bind；
• .ets 文件可以 import .ets/.ts/.js 源码，但 .ts/.js 文件不能 import .ets 源码。

这不是简单换文件后缀，而是会暴露存量代码里的隐式动态行为。比较现实的迁移策略是：

1. 领域模型先迁移：把接口返回、状态、实体类型改成显式 class/interface；
2. 消灭动态键访问：非标识符 key 改用 Map；
3. 隔离副作用：请求、存储、埋点、平台能力先通过接口抽象；
4. 页面逐个迁移：从稳定页面开始，不要先动活动页和实验页；
5. 测试资产前移：领域逻辑在纯 TS 层保持可测，再接 ArkUI。

5.2 Taro Harmony 迁移的真实成本#

Taro 能复用业务代码，但以下成本不能忽略：

• 鸿蒙工程链路：DevEco Studio、工程路径、hapName、签名、模拟器/真机调试必须有人负责；
• API 支持矩阵：每个 Taro API 都要确认 Harmony 目标上的行为，不支持处需要监听 __taroNotSupport 或写原生实现；
• 公共依赖库治理：默认内置公共依赖库不等于永远不动，版本、覆盖策略和升级影响要纳入依赖治理；
• UI 差异回归：同一组件在不同端的滚动、层叠、固定定位、表单、键盘行为可能不同；
• 性能热点局部原生化：关键页面需要原生组件时，团队仍要具备 ArkTS 能力；
• 发布口径变化：从小程序审核切到 AppGallery 发布、签名、多设备包体与版本管理。

所以，Taro 降低了「重写业务」的成本，但没有降低「理解 HarmonyOS」的成本。

5.3 迁移成本评分#

六、代码对照：同一个商品搜索页的两种实现#

下面示例刻意保持简单：输入关键词、过滤商品、点击加入购物车、显示状态。重点不是 UI 美观，而是比较状态、组件、事件和平台分支的组织方式。

6.1 Taro React 版本#

import { useCallback, useMemo, useState } from 'react'
import Taro from '@tarojs/taro'
import { View, Text, Input, Button, ScrollView } from '@tarojs/components'
import './index.scss'

interface Product {
  id: string
  name: string
  price: number
  stock: number
}

const PRODUCTS: Product[] = [
  { id: 'p1', name: 'HarmonyOS 开发键盘', price: 399, stock: 12 },
  { id: 'p2', name: 'ArkTS 桌面支架', price: 129, stock: 3 },
  { id: 'p3', name: 'Taro 跨端测试机架', price: 219, stock: 0 },
]

export default function ProductSearchPage() {
  const [keyword, setKeyword] = useState('')
  const [cartCount, setCartCount] = useState(0)
  const [message, setMessage] = useState('请输入关键词')

  const products = useMemo(() => {
    const word = keyword.trim().toLowerCase()
    if (!word) return PRODUCTS
    return PRODUCTS.filter((item) => item.name.toLowerCase().includes(word))
  }, [keyword])

  const addToCart = useCallback((product: Product) => {
    if (product.stock <= 0) {
      setMessage(`${product.name} 已售罄`)
      Taro.vibrateShort({ type: 'light' }).catch(() => undefined)
      return
    }

    setCartCount((count) => count + 1)
    setMessage(`已加入：${product.name}`)
  }, [])

  return (
    <View className="page">
      <View className="header">
        <Text className="title">商品搜索</Text>
        <Text className="cart">购物车 {cartCount}</Text>
      </View>

      <Input
        className="search"
        value={keyword}
        placeholder="搜索商品"
        onInput={(event) => setKeyword(event.detail.value)}
      />

      <ScrollView className="list" scrollY enableFlex>
        {products.map((product) => (
          <View key={product.id} className="row">
            <View className="info">
              <Text className="name">{product.name}</Text>
              <Text className="price">¥ {product.price}</Text>
            </View>
            <Button size="mini" disabled={product.stock === 0} onClick={() => addToCart(product)}>
              加入
            </Button>
          </View>
        ))}
      </ScrollView>

      <Text className="message">{message}</Text>
    </View>
  )
}

业务逻辑保持在 React/Taro 层，页面可以继续服务其他小程序端。鸿蒙差异应封装在 platform 适配层：

import Taro from '@tarojs/taro'

export function isHarmonyCpp(): boolean {
  return process.env.TARO_ENV === 'harmony_cpp'
}

export async function copyOrderNo(orderNo: string): Promise<void> {
  if (isHarmonyCpp()) {
    // 这里接入鸿蒙原生模块或项目内已验证的适配实现。
    return
  }

  await Taro.setClipboardData({ data: orderNo })
}

6.2 原生 ArkTS / ArkUI 版本#

interface Product {
  id: string
  name: string
  price: number
  stock: number
}

@Entry
@Component
struct ProductSearchPage {
  @State keyword: string = ''
  @State cartCount: number = 0
  @State message: string = '请输入关键词'
  private products: Product[] = [
    { id: 'p1', name: 'HarmonyOS 开发键盘', price: 399, stock: 12 },
    { id: 'p2', name: 'ArkTS 桌面支架', price: 129, stock: 3 },
    { id: 'p3', name: 'Taro 跨端测试机架', price: 219, stock: 0 },
  ]

  private filteredProducts(): Product[] {
    const word = this.keyword.trim().toLowerCase()
    if (word.length === 0) {
      return this.products
    }
    return this.products.filter((item: Product) => item.name.toLowerCase().includes(word))
  }

  private addToCart(product: Product): void {
    if (product.stock <= 0) {
      this.message = `${product.name} 已售罄`
      return
    }

    this.cartCount += 1
    this.message = `已加入：${product.name}`
  }

  build() {
    Column({ space: 12 }) {
      Row({ space: 12 }) {
        Text('商品搜索')
          .fontSize(22)
          .fontWeight(FontWeight.Bold)
        Blank()
        Text(`购物车 ${this.cartCount}`)
          .fontSize(14)
      }
      .width('100%')

      TextInput({ text: this.keyword, placeholder: '搜索商品' })
        .height(44)
        .onChange((value: string) => {
          this.keyword = value
        })

      List({ space: 8 }) {
        ForEach(this.filteredProducts(), (product: Product) => {
          ListItem() {
            Row({ space: 12 }) {
              Column({ space: 4 }) {
                Text(product.name)
                  .fontSize(16)
                Text(`¥ ${product.price}`)
                  .fontSize(14)
              }
              .alignItems(HorizontalAlign.Start)
              .layoutWeight(1)

              Button(product.stock === 0 ? '售罄' : '加入')
                .enabled(product.stock > 0)
                .onClick(() => {
                  this.addToCart(product)
                })
            }
            .width('100%')
          }
        }, (product: Product) => product.id)
      }
      .layoutWeight(1)
      .divider({ strokeWidth: 1, color: '#e5e7eb' })

      Text(this.message)
        .fontSize(14)
        .width('100%')
    }
    .padding(16)
    .height('100%')
  }
}

ArkUI 的状态管理官方说明非常关键：在声明式 UI 中，UI 是应用状态的执行结果；当状态参数变化时 UI 会更新。自定义组件中如果重渲染依赖某个变量，该变量必须使用装饰器，否则 UI 只会在初始化时渲染，后续不会更新。ArkUI 提供 V1/V2 两个状态管理版本，官方建议新应用直接评估 V2；已有 V1 应用如果功能与性能满足需求，不必立即切换。

因此，原生迁移时不能只翻译 JSX，还要重新设计状态所有权：哪些是页面状态、哪些是跨组件状态、哪些是应用级状态、哪些线程能访问状态。官方文档也提醒状态管理只能用于 UI 主线程，不能用于 Worker 或 TaskPool 子线程。

6.3 Taro 页面接入鸿蒙原生工程#

如果已有原生鸿蒙工程要接入 Taro 模块，官方文档给出的入口初始化结构如下：

import { context, Current } from '@taro-oh/library/src/main/ets/npm/@tarojs/runtime'
import { TaroWindowUtil } from '@taro-oh/library/src/main/ets/npm/@tarojs/runtime'

export default class EntryAbility extends UIAbility {
  onWindowStageCreate(stage: ohWindow.WindowStage) {
    context.resolver(this.context)
    TaroWindowUtil.setWindowStage(stage)

    stage.loadContent('home_page', (err, data) => {
      const windowClass = stage.getMainWindowSync()
      Current.uiContext = windowClass.getUIContext()
      windowClass.setWindowLayoutFullScreen(true)
    })
  }
}

这个示例说明了一个关键架构事实：Taro Harmony 不是「完全不碰 ArkTS」。一旦要集成原生工程、定制运行时或补齐 API，边界处仍然是 HarmonyOS/ArkTS 工程。

七、能力边界与架构分层建议#

无论选哪条路线，都建议把鸿蒙版分成五层，避免把平台差异散落在页面里：

1. 领域层：商品、订单、用户、库存等模型与业务规则，尽量平台无关；
2. 数据层：请求、缓存、同步、鉴权刷新，按端实现统一接口；
3. 平台能力层：剪贴板、振动、扫码、蓝牙、支付、推送、权限，使用能力探测和降级；
4. UI 层：页面组件、主题、设计系统；
5. 原生桥接层：Taro usingComponents / importNativeComponent，或原生 ArkTS 页面。

Taro 路线常见的问题是第 3 层被忽略，页面里到处写 process.env.TARO_ENV。原生路线常见的问题是第 1 层不存在，业务规则全部黏在 ArkUI 组件里，导致无法测试也无法迁移。两条路线都应该把平台判断压到适配层，而不是让每个页面自行猜测。

八、选型决策树#

按顺序回答以下问题：

1. 目标是继续在鸿蒙版微信/支付宝/抖音内运行小程序吗？
   是 → 不必立刻重写 ArkTS；先做宿主差异适配、平台识别和 API 降级。
   否 → 进入 2

2. 你要的是独立 HarmonyOS 应用/元服务吗？
   否 → 重新明确产品目标；不要为了技术潮流迁移。
   是 → 进入 3

3. 存量代码是否已经是 Taro，且核心业务页面可复用？
   是 → Taro Harmony-CPP 起步，先跑通工程、签名、真机和核心链路。
   否 → 进入 4

4. 鸿蒙版是否为长期战略主入口，计划持续投入团队？
   是 → 原生 ArkTS 主导；只把短生命周期活动页留给跨端方案。
   否 → 进入 5

5. 是否重依赖 HarmonyOS 系统能力、分布式、多设备协同或复杂原生交互？
   是 → 关键页面/模块原生 ArkTS，不做整站跨端。
   否 → 进入 6

6. 团队是否能接受 ArkTS 静态约束并重构领域模型？
   是 → 原生 ArkTS 或混合架构。
   否 → Taro 起步，同时建立原生组件逃生门能力。

8.1 推荐组合#

九、12 个高频踩坑#

1. 把 ArkTS 原生路线叫成「原生小程序」：产物是 HarmonyOS 应用/元服务，不是微信式小程序。术语混乱会导致发布、审核、签名和渠道预期全错。
2. 以为 Taro 可以完全绕过 DevEco Studio：官方路径仍包含鸿蒙工程、构建、签名、模拟器/真机调试。
3. 用 Previewer 验收 Taro Harmony：官方文档明确 Previewer 不适用于 Taro For Harmony 输出，UI 差异和性能结论不可靠。
4. 把 TypeScript 代码直接改后缀：ArkTS 禁 any、禁运行时改对象布局、不支持 structural typing 等约束会集中暴露存量问题。
5. 在 Worker/TaskPool 里直接操作 UI 状态：官方状态管理说明状态管理只能用于 UI 主线程。
6. 每个页面散落 TARO_ENV 判断：平台差异应收敛到平台能力层，否则测试矩阵不可维护。
7. 只写业务代码，不治理公共依赖库：Taro 插件默认使用内置公共依赖库，也支持禁用或指定版本；升级与覆盖策略必须纳入依赖治理。
8. 遇到不支持 API 直接空实现：官方提供 __taroNotSupport 事件做自定义实现；静默吞错会造成线上数据缺失。
9. 混淆 HAP 与 APP：HAP 用于本地调试，APP 用于发布；APP 不能本地安装，真机 HAP 需要签名。
10. 用模拟器出性能结论：Taro 文档说明模拟器无法使用 IDE Profiler 测性能；关键性能指标用真机。
11. 只比较包体总大小：要看 HAP 明细、资源、依赖库、多设备包与最终发布产物，统一调试/发布口径。
12. 把「能编译」当成「能发布」：签名、权限、多设备、隐私、审核、升级与回滚是独立工程项，必须在试点阶段走通。

十、落地试点清单#

• 明确产品形态：超级 App 内小程序、独立应用、元服务，还是混合；
• 盘点存量页面与 API，标注必须原生化的热点；
• 建立统一 platform 适配层，禁止页面内随意写端判断；
• Taro 项目安装 Harmony-CPP 插件并确认 compiler: 'vite'；
• 配置 projectPath 与 hapName，纳入版本管理策略；
• 跑通 taro build --type harmony_cpp；
• 如需原生组件，验证 usingComponents / importNativeComponent；
• 原生工程接入时核对 context.resolver、TaroWindowUtil.setWindowStage、Current.uiContext；
• 为不支持 API 建立 __taroNotSupport 记录与降级清单；
• 决定公共依赖库使用内置、禁用还是指定版本，并记录原因；
• 搭建模拟器与纯鸿蒙真机回归环境；
• 建立冷启动、首屏、列表、输入、动画、内存、耗电基线；
• 区分 HAP 调试包与 APP 发布包，统一包体统计口径；
• 梳理签名、证书、权限、隐私声明与 AppGallery 发布流程；
• 制定灰度、崩溃监控、性能监控和回滚方案；
• 让至少一名工程师具备 ArkTS 原生组件逃生门能力。

十一、官方来源核对#

本文事实与配置片段核对自以下官方文档：

• ArkTS 定位、常用库、TaskPool/Worker、Sendable、ArkCompiler/*.abc：华为 HarmonyOS 官方文档《ArkTS — About This Kit》。
• ArkTS 对 TypeScript 特性的限制：华为 HarmonyOS 官方文档《从 TypeScript 到 ArkTS 的适配规则》，包括静态类型、any、对象布局、structural typing、index signature、delete、globalThis、Function.apply/call/bind 等约束。
• ArkUI 状态管理：华为 HarmonyOS 官方文档《State Management Overview》，包括状态驱动 UI、装饰器、V1/V2、新应用建议评估 V2、状态管理仅 UI 主线程可用。
• Stage 模型配置：华为 HarmonyOS 官方文档《Application Configuration File (Stage Model)》：一个 app.json5，一个或多个 module.json5。
• Taro Harmony 插件安装与配置：Taro 官方文档《Harmony-CPP 插件安装和使用》：@tarojs/plugin-platform-harmony-cpp、compiler: 'vite'、projectPath、hapName、useChoreLibrary、usingComponents、importNativeComponent、__taroPluginEtsMethodsTrigger、__taroNotSupport。
• Taro Harmony 工程与调试：Taro 官方文档《初始化流程和结构介绍》：Stage 模型、ArkTS/ArkUI、Previewer 不适用于 Taro For Harmony、模拟器与纯鸿蒙真机建议。
• HAP/APP、签名与发布差异：AppGallery Connect 官方帮助中心《Releasing an App FAQ》。

反古德哈特声明：本文不提供未经来源核实的 Taro 版本号、HarmonyOS API 版本、DevEco Studio 版本、包体上限或性能百分比。项目落地时请以你当前 SDK、插件版本、目标设备和官方最新文档为准，并用同一业务页面建立自己的测量基线。