文章导读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 更可靠。