先交代背景，避免你觉得我在纯吹或者纯黑。我过去五年主要是写Android的，帮上家公司做过两个上线了的音视频应用，对Kotlin、协程、Compose还算熟。2024年10月中旬，公司因为所谓“鸿蒙应用专区”的流量和装机数据连续三个月涨了接近40%，开始临时组建鸿蒙适配小组，而我当时是唯一没有同时挂在两个项目上的Android开发……所以我不幸成了第一批去ArkTS里踩坑的人。整篇文章不打算给鸿蒙背书，也不打算黑它，只记录一个普通移动端开发转向鸿蒙之后，最麻烦、最不习惯、但也觉得最值得关注的地方。
先说最直观的工具链体验。我用的环境是Windows 11 + DevEco Studio 5.0.3.810（后面又频繁更新过几次），手机是单位发的nova系列临时测试机，系统HarmonyOS 5.0.1，也就是API 12那一批，中间还抽出两台升到过API 15的开发版。和Android Studio比，DevEco Studio有两点很意外：一是新建工程到跑起模拟器的成功率高，基本没有遇到过Gradle卡在下载依赖里的玄学问题；二是它对内存的占用真不低，16G的办公笔记本开两个项目直接开始掉帧，编译冷启动经常能看到3GB到4GB的内存波动。hvigor的增量构建比Gradle体感快一些，几十个模块的工程改完一个详情页，从点击Build到装上模拟器大概只需要几十秒；但全量编译还是得等，我第一次配鸿蒙SDK时因为路径有中文名还会在NDK步骤里报错，后来老老实实把整个SDK挪到纯英文路径才顺利跑通。
真正让Android开发难受的，是ArkTS严格模式。社区里有种玩笑说法叫ArkTS是TypeScript的“双胞胎严管版”，我一开始觉得夸张，直到接手一个从uni-app迁移过来的页面，发现里面有几十个地方绕过了 no-explicit-any 这条规则，打开严格检查后满屏报错。后来我们的处理方式是：把所有接口返回先定义成interface，再写一个手工映射函数做类型收敛，这样虽然前期工作量增加，但后面改字段时基本不会再有运行时的诡异崩溃。老实讲，在Kotlin里我们也做类似的事，但ArkTS这回等于直接逼着你做，没法偷懒。这个映射文件后来成了好几个页面的公共依赖，代码规整度确实提高了不少。
如果你已经开始写鸿蒙页面，那你八成会被状态管理坑过。 @State 装饰一个普通对象，里面某个嵌套字段被改了，外部页面却不刷新，这个问题在我们项目里出现了好几次。最后用的方案很简单：把需要联动的数据拆成独立的 @State 基础类型字段，或者用 @Observed 加上 @ObjectLink 把嵌套对象变成可观察的结构。如果你是在API 12以上的版本做新功能，可以试一下 @Monitor 去监听属性变化，但遇到复杂结构时个人不建议硬用。另一个特别实际的坑是列表长图或者视频封面资源多的时候， ListItem 在快速滑动后会出现闪白，用 LazyForEach 时如果没提供一个稳定的keyGenerator，刷新后位置还会莫名其妙闪动，这个问题和ArkUI的复用机制有关，代码大致是这样：
LazyForEach(this.dataList, (item) => {
ListItem() {
Image(item.cover).width('100%').height(200)
}
}, (item) => item.id)注意最后这个keyGenerator不能省，也不能只写成固定数字index，否则图片加载时会出现旧资源被复用，导致封面和标题不匹配。
把鸿蒙和Android放到同一张桌上对比的话，我的独立观点是：它在“系统级联动”和“桌面入口分发”上确实改变了游戏规则，但它在传统代码开发体验上并不存在什么“底层颠覆式的奇迹”。服务卡片FormExtensionAbility就是一个例子，Android的AppWidget要做远程View，限制多还经常被厂商清理掉；鸿蒙这边卡片可以直接进桌面，用户不用先启动一次App。我们做的一款简单天气记录工具上架之后，从卡片点击重新进入应用的比重比之前Android版本高了差不多70%，这个数据是我们自己对两个平台的统计粗算出来的，不算严谨，但趋势很真实。但反过来说，鸿蒙的调试工具命名是真的散，日志用hilog，命令行叫hdc，IPC相关API又跟Android AIDL的思路不太一样，遇到找不到答案的问题时只能去开发者论坛翻老帖。鸿蒙开发者里面很多都是年轻朋友，说到底大家都是在同一片坑地里边写边摸路，但这些坑恰好也意味着竞争还没那么挤。
最后说一点偏实操的建议。如果你想从Android或前端转过来，不用急着买各种高价课。先把官方Codelab上的购物页示例敲完，把页面路由和状态管理的练习搞定，然后去开发者论坛搜“API 12 @State 刷新”和“LazyForEach keyGenerator”这类关键词，看满十个帖子之后基本能避开新手期的第一波大坑。再往后就是Stage模型、Ability生命周期和 @Builder 复用这些概念了，建议用真机调，别只依赖Previewer预览器，很多布局问题只有真机跑一遍才能暴露出来。我的体感是鸿蒙当前的坑其实没有比十年前Android更多，但文档和最佳实践的迭代速度还在追赶，所以搜索成本会比较高。如果未来两个大版本能把状态管理和调试体验再收紧一点，应该会留得住更多人；但如果你是现在就想进场找机会，那花三个月专门去把API 15这一代吃透，可能已经比大多数还停留在看热闹阶段的人领先一截了。