春卷同学的博客

Computed是 ArkTS V2 体系中处理派生状态的声明式方案，核心价值在于"声明依赖、自动推导、按需缓存"。与手动同步相比，它消除了遗漏更新和代码冗余两大痛点；与@Watch相比，它专注于派生值的计算而非副作用执行。@Computed支持链式依赖，可以构建从源数据到最终 UI 展示的完整转换管道。在实际使用中，应牢记"无副作用、无参数、纯 getter"的约束，并善用缓存机制来优化频繁读取的场景。

和@Trace是 ArkTS V2 状态管理的基石。通过将检测粒度从类级降到属性级，V2 在架构层面解决了 V1"牵一发而动全身"的性能问题。核心设计理念是"白名单机制"——只有被@Trace标记的属性才参与响应式追踪，其余属性保持普通数据行为。配合@Type装饰器，V2 实现了数组和对象的深度属性级追踪，为复杂数据驱动的 UI 场景提供了坚实的基础。在实际开发中，开发者应遵循"最小化响应式范围"的原则，仅对直接绑定 UI 的属性使用@Trace，以获得最佳性能表现。

MoneyTrack 的测试体系通过 hypium 测试框架建立了一套规范化的分层测试架构。本地单元测试（src/test/）覆盖纯逻辑和工具类函数，提供快速反馈；仪器化测试（src/ohosTest/``）覆盖 Ability 生命周期和 UI 交互，保障核心流程的正确性。每个模块的双测试目录结构、统一的注册机制和完善的module.json5` 配置，共同构成了一个可维护、可扩展的测试基础设施。

MoneyTrack 的资源体系充分利用了 HarmonyOS 提供的资源管理能力，通过base/zh_CN/en_US/dark/等多维度资源限定词目录，实现了多语言国际化、深色模式适配和设备差异化呈现。$r()和$m()编译期资源引用 API 在保证性能的同时，提供了类型安全的资源访问方式。模块化的资源组织策略（AppScope 全局资源 + HAR 模块私有资源）兼顾了共享与隔离的需求。

MoneyTrack 从个人记账到家庭记账的演进过程，展示了如何通过合理的架构设计实现功能的无缝扩展。核心策略包括：数据模型的可选字段扩展（向后兼容）、RouterMap 枚举追加（路由集中管理）、模块低耦合分散部署（避免单点变更影响全局）、以及 ViewModel 层的筛选逻辑复用（UI 与业务逻辑分离）。架构扩展的精髓不在于一开始就设计出一个完美的系统，而在于对变化保持敏感、坚持良好的设计原则（OCP、ISP、SRP），并在每一次功能迭代中持续优化。

EventBus 是 MoneyTrack 跨模块通信的核心基础设施，它基于 HarmonyOS 的 EventHub 封装，提供了全局事件发布订阅能力。与 emitter 系统事件、@Prop/@Link 组件绑定一起，构成了分层的通信体系。EventBus 负责全局业务状态同步，emitter 负责轻量级系统通知，@Prop/@Link 负责组件树内的数据传递。三者各司其职、互补共存。

MoneyTrack 的 ViewModel 模式实践表明，在鸿蒙 ArkTS 生态中，借助@Trace和@Computed装饰器，可以高效地实现 MVVM 架构。HomeVM、AssetsVM、MineVM 三个 ViewModel 各司其职，分别管理首页账单、资产管理和个人中心的状态与业务逻辑，使得视图组件保持纯粹和简洁。ViewModel 与 View 之间的数据流是单向的——ViewModel 通过@Trace字段向 View 推送数据，View 通过调用 ViewModel 的方法触发状态变更。

在bill_base模块的Types.ets中，定义了多个接口，如。note?: string;assetId?: number;assetName?: string;memberId?: number;memberName?: string;isCustom?: number;接口的最大优势在于可被任意模块引用（包括非 UI 模块，如数据层或工具库commonlib），不引入响应式开销，适合作为跨模块数据传输的契约。bill_base。

MoneyTrack 的工程全景展现了鸿蒙 Stage 模型下多模块应用的标准布局。从 AppScope 的全局配置到每个模块的自包含结构，从 module.json5 的 Ability 注册到 hvigor-config.json5 的构建优化，每个配置文件都有其明确的职责。理解这一工程结构，不仅能帮助开发者快速上手 MoneyTrack 项目，更能为构建自己的鸿蒙应用提供可复用的蓝图。

多模块 HAR 架构是鸿蒙大型应用工程的基石。MoneyTrack 通过四层架构的精心设计，实现了 21 个模块的高内聚低耦合。通用层提供基础设施，组件层封装可复用的业务组件和数据模型，特性层聚合领域页面，入口层完成最终组装。配合单向依赖原则、接口隔离和统一的包导出设计，这一架构支撑了项目的快速迭代和团队高效协作。在实际项目中，应根据业务复杂度灵活调整模块粒度，始终将"可维护性"和"可扩展性"作为架构设计的首要目标。