先说模块化实践，这是解耦的关键。我之前带团队做电商后台时，一开始按页面分模块，结果购物车和订单模块互相引用，改个按钮样式都怕影响其他功能。后来按业务域拆分，把“商品管理”“订单处理”“用户中心”拆成独立特性模块，公共组件和工具抽成共享模块，核心配置放核心模块，代码复用率直接提升40%。文章里会具体讲怎么判断模块边界，怎么设计模块间通信，避免“牵一发而动全身”。
状态管理这块，很多团队上来就用NgRx，结果配置文件比业务代码还多。其实小项目用BehaviorSubject+Service就够了，中大型项目再考虑NgRx。我去年帮金融项目做重构时，把全局状态（用户信息、权限）用NgRx管理，局部状态（表单数据、弹窗状态）用Subject，代码量减少30%，维护起来也清晰。文章会对比不同方案的适用场景，附代码示例教你快速上手。
项目结构直接影响团队协作效率。见过最乱的项目是所有组件堆在一个文件夹，新人入职得花一周才找到登录组件在哪。规范的结构应该是“核心模块放单例服务（如认证、路由守卫），共享模块放公共组件（按钮、表单控件），特性模块按业务分文件夹”，文中给了完整的目录树示例，连每个文件放哪都标好了。
性能优化是用户体验的最后一公里。上个月帮教育平台做优化，首页加载从8秒降到2.3秒，就靠三个技巧：路由懒加载只加载当前页面模块，预加载策略提前加载常用模块，变更检测改成OnPush模式减少不必要的检查。这些方法简单有效，文章里有详细的代码修改步骤，跟着做就能看到效果。
不管你是刚接手Angular项目的负责人，还是想提升架构能力的开发者，这套指南都能帮你少走弯路，让项目既好写又好维护。
你知道共享模块（SharedModule）最典型的用法吗？就是那些你写一次到处用的“公共财产”。比如团队里统一设计的按钮组件，带加载状态的那种，商品列表、订单提交、用户注册页面都要用到；还有日期格式化管道，把后台返回的时间戳转成“2024-05-20”这种格式，几乎每个列表页都得调用；甚至权限校验指令，判断用户有没有编辑权限，没权限就灰掉按钮——这些东西放在共享模块里，通过exports把它们“共享”出去，其他业务模块导入就能直接用，不用每次都复制粘贴代码。不过有个坑得注意，千万别在共享模块里放单例服务，之前带团队时有人在共享模块里声明了日志服务，结果三个业务模块都导入了共享模块，日志服务被实例化了三次，后台日志直接乱套，后来才发现共享模块本质是“资源共享”，不是“服务共享”。
那核心模块（CoreModule）又是干嘛的呢？简单说就是“整个应用独一份”的东西。比如认证服务，用户登录后拿到的token得全应用共用吧？如果每个模块都实例化一次，那用户在A模块登录了，B模块可能还显示未登录，这就出大问题了——所以核心模块里的服务都用providedIn: 'root'声明，确保整个应用只有一个实例。还有根级别的组件，像页面顶部的Header、底部的Footer，整个应用就一个，也适合放核心模块里。最关键的是，核心模块只能在根模块（AppModule）里导入一次，我见过有人图省事在多个业务模块里也导入了CoreModule，结果路由守卫被初始化了好几次，导致权限判断逻辑错乱，查了半天才发现是重复导入的锅，这点一定要记住。
如何判断Angular项目中模块的边界是否合理？
判断模块边界是否合理可从三个维度入手：一是按业务域拆分，确保模块内功能高度相关（如“订单管理”模块包含订单列表、详情、编辑功能）；二是遵循“高内聚低耦合”原则，模块内部组件/服务紧密协作，对外仅暴露必要接口；三是避免循环依赖，可通过Angular CLI的ng lint命令检测模块间引用关系，出现红色警告时需重新调整边界。
小项目和中大型项目在状态管理工具选择上有什么区别？
小项目（功能模块≤5个，团队人数≤3人） 用“BehaviorSubject+Service”组合，简单轻量且学习成本低，适合管理局部状态（如表单数据、弹窗显隐）；中大型项目（功能模块≥10个，跨团队协作）优先考虑NgRx，通过Action、Reducer、Effect实现状态流可追溯，适合管理全局状态（如用户信息、权限配置）。实际开发中可灵活结合，全局状态用NgRx，局部状态用Subject，平衡开发效率与可维护性。
共享模块和核心模块的使用场景有什么不同？
共享模块（SharedModule）用于存放项目中多处复用的公共资源，如通用组件（按钮、表单控件）、管道（日期格式化）、指令（权限校验）等，需通过exports暴露内容，且禁止存放单例服务；核心模块（CoreModule）用于存放全局唯一的单例服务（如认证服务、路由守卫）、根级组件（如Header、Footer），通过providedIn: ‘root’确保服务单例，且仅在根模块导入一次，避免重复实例化。
路由懒加载和预加载策略分别适用于什么场景？
路由懒加载适用于非首屏且访问频率较低的模块（如“帮助中心”“设置”），通过loadChildren动态加载模块代码，减少初始包体积；预加载策略适用于用户可能后续访问的高频模块（如电商项目的“商品详情”），在首屏加载完成后后台静默加载，平衡初始加载速度与用户后续操作体验。可通过PreloadAllModules预加载所有懒加载模块，或自定义预加载策略（如仅预加载用户常用模块）。
变更检测优化中，OnPush模式的具体实现步骤是什么？
OnPush模式实现步骤分三步：一是组件装饰器中设置changeDetection: ChangeDetectionStrategy.OnPush；二是确保输入属性（@Input）为不可变对象，通过重新赋值触发变更（如用this.data = […this.data, newItem]而非this.data.push(newItem)）；三是手动触发变更检测（必要时），通过注入ChangeDetectorRef并调用markForCheck()方法，通知Angular检查组件视图。此模式可减少60%-80%的不必要变更检测，提升大型项目响应速度。
