一、项目背景
本次项目的核心需求，是开发一款能够同时支持：
HarmonyOS NEXT（鸿蒙）
微信小程序
Android
iOS
的跨端应用。
由于项目目标平台较多，因此前期重点工作主要集中在：
技术框架选型
开发环境搭建
鸿蒙生态兼容验证
富文本编辑器方案调研
跨平台开发效率评估
在近几天的实际开发与测试过程中，主要尝试了以下三种技术路线：
Flutter 鸿蒙版（OpenHarmony Flutter）
uni-app x
Taro
最终综合开发效率、生态稳定性、鸿蒙支持程度以及后期维护成本后，初步倾向选择 Taro 作为当前阶段的主开发方案。
二、三种技术方案的实际测试与评价
1. Flutter 鸿蒙版（OpenHarmony Flutter）
1.1 选择 Flutter 的原因
Flutter 本身是一套成熟的跨平台开发方案：
UI 一致性高
性能优秀
社区生态成熟
Dart 语言开发效率较高
理论上非常适合作为跨平台 App 技术方案。
因此最开始优先尝试了 Flutter 鸿蒙版。
1.2 实际开发过程中遇到的问题
在实际环境配置过程中，发现 Flutter 鸿蒙版目前仍处于快速迭代阶段，整体稳定性与官方 Android/iOS 生态存在明显差距。
主要问题包括：
（1）环境变量识别不统一
Flutter CLI、DevEco Studio、Hvigor 构建工具之间存在环境识别差异。
经常出现：
终端可以正常 build
IDE 点击运行失败
SDK component missing
No Hmos SDK found
等问题。
本质上是：
不同工具读取的环境变量上下文并不一致。
（2）SDK 版本兼容问题严重
鸿蒙 SDK 下载的是较新版本（如 API 23），但 Flutter 鸿蒙工具链只能识别较旧版本（如 API 12 或 API 15）。
导致：
SDK 实际存在
hf doctor 仍判定 SDK 无效
甚至需要手动修改 sdk-pkg.json 文件进行“伪装”。
（3）PATH 路径冲突问题
由于电脑中同时存在：
标准 Flutter
鸿蒙 Flutter
IDE 有时会错误调用标准 Flutter 的 dart 引擎。
结果导致：
无法识别鸿蒙工程
无法处理 .hap
模拟器无法连接
该问题排查耗时较长。
（4）开发体验不稳定
当前阶段：
IDE 运行按钮不稳定
热重载依赖终端
原生构建流程较复杂
最终只能采用：
hf run配合：
r进行终端热重载开发。
1.3 Flutter 鸿蒙版的优点
虽然配置复杂，但 Flutter 鸿蒙版仍然有明显优势：
优点
UI 表现力强
动画能力优秀
Flutter 本身开发体验成熟
Dart 语法较规范
适合复杂 App
1.4 Flutter 鸿蒙版当前阶段的问题总结
目前最大的问题并不是代码开发，而是：
“环境配置成本远高于正常开发成本”。
大量时间消耗在：
SDK 对齐
环境变量修复
工具链兼容
DevEco 配置
对于项目快速推进不太友好。
因此现阶段不适合作为主技术方案。
2. uni-app x 技术方案
2.1 尝试 uni-app x 的原因
uni-app x 主打：
原生性能
多端统一
支持鸿蒙
DCloud 官方生态
理论上也非常适合作为跨平台方案。
因此后续又测试了 uni-app x。
2.2 实际开发过程中遇到的问题
（1）语法体系与传统前端差异较大
uni-app x 使用的是：
UTS（Uni TypeScript）
而不是普通 JavaScript 或 TypeScript。
其特点是：
强类型
静态编译
编译限制严格
因此很多 Web 开发习惯无法直接使用。
（2）AI 生成代码错误率较高
这是开发过程中最明显的问题之一。
目前网络上的：
uni-app
Vue
JavaScript
资料很多。
但：
uni-app x 的公开资料仍然较少。
导致 AI 在生成代码时，经常：
混用旧版 uni-app API
使用错误类型
使用不存在的方法
引用旧语法
例如：
createSelectorQuery
uni.request
WebviewElement
等旧版写法。
实际在 uni-app x 中会直接编译失败。
（3）富文本编辑器集成复杂
项目中需要富文本编辑能力。
但 uni-app x App 端并不是浏览器环境。
因此：
依赖 DOM 的 Web 编辑器无法直接运行。
最终只能采用：
web-view + HTML 页面方式进行桥接。
核心方案是：
web-view 内运行 Textrix 编辑器
uni.webview.js 做通信桥梁
原生页面与 Web 页面进行消息同步
该方案虽然可行，但整体复杂度较高。
2.3 uni-app x 的优点
优点
原生性能较好
多端支持能力强
官方支持鸿蒙
编译效率较高
适合轻量型业务应用
2.4 uni-app x 当前阶段的问题总结
当前阶段最大的困难是：
“生态资料不足”。
尤其：
AI 辅助能力较弱
可参考案例较少
编译器规则严格
第三方库兼容有限
开发过程中需要频繁查阅官方文档。
整体开发门槛偏高。
3. Taro 技术方案（当前预选方案）
3.1 为什么最终倾向选择 Taro
在经过 Flutter 鸿蒙版与 uni-app x 的实际测试后，最终开始重点调研 Taro。
原因主要包括：
（1）React + TypeScript 开发生态成熟
Taro 基于：
React
TypeScript
Node.js
整体开发模式更加接近现代 Web 前端。
开发体验更加统一。
（2）AI 辅助开发效果明显更好
由于：
React
TS
Web 技术
互联网资料非常丰富。
因此 AI 生成代码准确率明显更高。
整体开发效率提升明显。
（3）鸿蒙适配方案更加清晰
京东官方提供：
@tarojs/plugin-platform-harmony-hybrid插件。
Taro 可通过：
npm run dev:harmony-hybrid启动本地 Dev Server。
然后通过：
DevEco Studio
ArkUI Web 容器
加载本地页面。
整体开发流程更加清晰。
（4）热更新开发体验较好
采用局域网热更新方案后：
修改代码即可实时刷新
无需频繁重新打包
开发调试效率明显提高
这一点相比 Flutter 鸿蒙版体验更稳定。
3.2 Taro 的优点
优点
React 生态成熟
TypeScript 支持完善
AI 辅助开发效果好
小程序支持成熟
Web 开发模式统一
鸿蒙适配方案较清晰
社区活跃度较高
3.3 Taro 当前的不足
目前 Taro 更偏：
Hybrid
WebView 容器方案
因此：
原生能力深度不如 Flutter。
对于：
高性能动画
复杂原生交互
大型重度 App
仍然存在一定限制。
但对于当前项目阶段来说，已经能够满足需求。
三、这几天重点完成的工作
近期主要完成了以下工作：
1. 鸿蒙开发环境调研与搭建
包括：
DevEco Studio
HarmonyOS SDK
Flutter 鸿蒙工具链
Hvigor 构建环境
HDC 真机调试
并解决了：
SDK 识别失败
环境变量冲突
PATH 优先级问题
模拟器连接失败
等问题。
2. Flutter 鸿蒙版完整测试
完成了：
hf doctor
hf build hap
hf run
热重载调试
并验证了：
Flutter 鸿蒙版当前阶段的实际开发可行性。
3. uni-app x 富文本编辑器方案验证
重点完成了：
web-view 通信方案
Textrix 编辑器接入
uni.webview.js 消息桥接
App 与 Web 双向通信
验证了：
uni-app x 中富文本编辑器的可实现方案。
4. Taro 鸿蒙混合开发方案调研
完成了：
Taro CLI 环境配置
harmony-hybrid 插件测试
Dev Server 热更新测试
ArkUI Web 加载验证
并基本打通：
“Taro + 鸿蒙 + 小程序”的开发闭环。
四、当前阶段的建议方案
结合目前测试结果：
当前更推荐：
Taro + React + TypeScript
作为项目第一阶段的主开发方案。
原因主要是：
开发效率更高
AI 辅助效果更好
小程序生态成熟
鸿蒙适配方案清晰
环境稳定性优于 Flutter 鸿蒙版
学习与维护成本较低
五、总结
本次技术选型过程中，重点并不只是“哪个框架最好”，而是：
“哪个框架更适合当前项目阶段”。
经过实际环境搭建、跨端测试以及鸿蒙适配验证后，可以得出的结论是：
Flutter 鸿蒙版性能强，但当前配置复杂度较高
uni-app x 原生能力不错，但生态仍在完善阶段
Taro 在开发效率、稳定性以及跨端支持方面更均衡
因此，现阶段更适合采用 Taro 作为主要技术方案推进项目开发。