文章导读

• entry 层负责应用入口与页面壳，不承载复杂业务。
• features 层承载业务页面和数据仓库，页面之间通过 common 的 Nav 和 Routes 协作。
• common 层提供主题、模型、组件和工具，避免页面之间互相引用。

页面效果

首页能稳定承载四个主 Tab，说明入口层只负责组织页面；业务页面、通用组件和模型各自保持边界。

实战拆解

HarmonyOS 项目做大以后，最容易出现的问题是页面、组件、模型互相穿插。羽球联盟采用 entry、features、common 三层结构，是为了让入口壳、业务页和基础能力分开演进。entry 的 Index 页面只组合四个主 Tab，不直接管理赛事、装备、球员等业务细节。

features 是业务能力层，HomePage、EventListPage、EquipmentListPage、PlayerFeedPage、ProfilePage 等页面都从这里导出。这样 entry 只依赖 features 的公开入口，不需要知道每个页面内部怎样查数据、怎样做下拉刷新。

关键代码

// 入口只依赖公开能力，不穿透到业务内部实现
import { HomePage, EventListPage, PlayerFeedPage, ProfilePage } from 'features';
import { AppColors, Nav, Routes, ArticleCard } from 'common';

这里强调的是公开依赖关系：入口知道能使用哪些页面和能力，但不关心它们内部怎样组织数据。

取舍分析

这里的取舍可以从两个方向看：一边要让当前页面足够直观，用户打开后能马上理解入口、状态和反馈；另一边要给后续迭代留下余量，避免把数据处理、视觉样式和跳转逻辑全部写死在同一个地方。入口层只组合页面，不直接理解赛事、装备、球员等业务细节。 业务页通过公开入口向外暴露，减少跨层引用带来的耦合。

设计落点

• 入口层只组合页面，不直接理解赛事、装备、球员等业务细节。
• 业务页通过公开入口向外暴露，减少跨层引用带来的耦合。
• 主题、模型、路由和组件沉到公共层，后续替换视觉或导航实现更轻。

易踩坑

• 不要让 common 反向依赖 features，否则公共层会失去稳定性。
• 不要在 entry 层堆业务判断，否则 Tab 壳会变成难维护的上帝页面。

验证方式

• 从入口页切换到不同业务页，确认一级导航稳定。
• 新增业务入口时优先复用公开页面能力。
• 调整公共样式后观察多个页面是否同步变化。

小结

entry、features、common三层工程拆分 的价值在于把页面现象和工程边界放在一起看：用户看到的是流畅的入口、列表、详情和反馈，开发者真正维护的是状态、模型和组件之间的关系。这个思路迁移到其他 ArkTS 项目时，比单独记某个 API 更可靠。