Ionic 3技术咨询：每个页面是否需要独立的Module？

嘿，作为刚接触Ionic的开发者，纠结页面模块的组织方式太正常了——我当初也踩过类似的坑！咱们一步步拆解你的问题：

核心问题：页面该独立建Module还是按类归组？ #

1. 按同类页面归组到同一Module：更推荐的中型应用方案 #

这种分组完全可行，而且是中型项目里更合理的选择，原因如下：

• 逻辑内聚：把同一业务域的页面（比如后台的用户管理、权限设置、用户详情页）放到同一个Module里，后续维护时找相关功能会更顺畅，业务逻辑的关联性也更清晰。
• 避免冗余：不用为每个页面重复创建结构几乎一致的Module文件，减少项目里的“噪音文件”。

需要注意的是，虽然IonicPageModule.forChild()只能接受单个页面，但你可以在同一个Module里多次调用它，把所有相关页面都注册进去。举个实际的代码例子：

@NgModule({
  declarations: [
    AdministerUsersPage,
    UserDetailsPage,
    PermissionSettingsPage
  ],
  imports: [
    CommonModule,
    FormsModule,
    IonicModule,
    // 为每个页面单独调用forChild
    IonicPageModule.forChild(AdministerUsersPage),
    IonicPageModule.forChild(UserDetailsPage),
    IonicPageModule.forChild(PermissionSettingsPage)
  ]
})
export class AdminModule {}

2. 每个页面单独创建Module：可行但弊端明显 #

这种方式技术上完全没问题，Ionic本身支持单个页面对应一个Module，但在中型应用里这么做会带来不少问题：

• 文件爆炸：每个页面都要新增一个xxxPageModule.ts文件，项目里会多出大量重复的模块定义，文件结构变得臃肿，找文件的成本大大增加。
• 编译效率降低：Angular的编译过程需要处理每个模块，模块越多，开发模式下的增量编译速度会变慢，影响开发效率。
• 逻辑分散：相关业务的页面被拆成独立模块后，跨页面的共享组件、服务需要额外抽成共享模块，反而增加了代码的复杂度，不如归组后直接在同一模块内复用方便。

总结建议 #

对于中型Ionic应用，优先按业务域/功能模块来分组创建Module，比如用户模块、订单模块、商品模块，每个模块下包含该业务的所有相关页面。这种方式既保证了代码的组织性，又避免了模块过多带来的冗余问题。

如果是完全独立、和其他业务无关联的页面（比如登录页、404错误页），单独创建Module是可以的，但这种情况在中型项目里应该是少数。

内容的提问来源于stack exchange，提问作者emulcahy