架构层：从源头避免“牵一发而动全身”的耦合陷阱
很多人做Angular项目，一开始总想着“先实现功能再说”，结果代码像野草一样乱长——组件里写业务逻辑，服务里调DOM操作，模块里什么都塞。等项目大了才发现，改个按钮样式可能影响三个页面，删段废弃代码怕崩了整个系统。其实可扩展性不是“后期优化”出来的，而是从架构设计阶段就该埋下的种子。
模块化设计：按“业务域”拆分，而不是“功能类型”
你打开自己的项目看看，是不是把所有表单组件放一个模块，所有列表组件放一个模块？我见过最夸张的案例，有个团队把所有HTTP请求都塞在一个“ApiService”里，结果这个服务有1500行代码，改个用户接口得翻半天。后来我们帮他们按业务域拆分成“UserModule”“OrderModule”“ProductModule”，每个模块里放自己的组件、服务、路由，模块间通过“公共接口”通信，而不是直接引用内部组件。
为什么按业务域拆分更抗扩展？举个例子，用户模块里的“用户列表”和“用户详情”组件，它们的数据、逻辑高度相关，放一起修改时不会影响其他模块；但如果把所有“列表组件”放一起，用户列表改个分页逻辑，可能会误动到商品列表的代码。Angular官方文档里也强调“Feature Module”（特性模块）的设计理念，就是让每个模块聚焦一个业务域，你可以看看Angular官方关于特性模块的指南，里面有详细的划分原则（记得加nofollow标签哦）。
你可以现在就做个小检查：打开项目的模块文件，看看 imports 数组里有没有跨业务的组件或服务？比如 OrderModule 里引用了 ProductComponent？如果有，说明模块边界已经模糊了，得赶紧调整。我之前帮那个电商团队拆分模块时，先画了张“业务域关系图”，把每个模块的输入输出接口列出来，再用 Angular 的 exports 配置只暴露必要的组件/指令，三个月后他们团队反馈“终于敢放心改代码了”。
依赖注入：让服务“可插拔”，而不是“硬编码”
刚用Angular时，很多人习惯在组件里直接 new UserService() 创建服务实例，觉得“简单直接”。但项目一大，你会发现根本没法替换服务——比如测试时想 Mock 一个假的用户服务，或者线上环境想用不同的 API 地址，硬编码的服务根本改不了。这就是为什么 Angular 要设计“依赖注入（DI）”机制，你可能听过这个词，但不一定清楚它到底怎么帮代码扩展。
简单说，依赖注入就是“谁用服务谁不创建，让 Angular 容器来提供”。比如你在组件里声明 constructor(private userService: UserService) {}，Angular 会自动帮你创建 UserService 实例，你不用管它怎么来的。这样做的好处是：想换服务时，只需要在模块的 providers 里配置替换类，比如测试时用 { provide: UserService, useClass: MockUserService }，所有用到 UserService 的组件都会自动用 Mock 版本，完全不用改组件代码。
我之前带过一个实习生，他写的组件里全是 new 出来的服务，后来项目要接两个环境（测试/生产）的 API，他改了三天都没改完，因为每个组件都要手动切换服务地址。后来我教他用依赖注入+环境配置，把 API 地址放 environment.ts 里，服务通过 DI 获取地址，一天就搞定了。现在他写组件时，第一件事就是在构造函数里声明服务依赖，还跟我说“这招比硬编码爽太多了”。
如果你还在用 new 创建服务，现在就可以改：先把服务加上 @Injectable({ providedIn: 'root' }) 装饰器，然后在组件里通过构造函数注入。记着别在服务里写死具体实现，比如 HTTP 请求地址、第三方库调用，这些都可以通过参数注入，比如 @Inject('API_URL') private apiUrl，再在模块 providers 里配置 { provide: 'API_URL', useValue: environment.apiUrl }。这样不管环境怎么变，服务本身不用改，扩展性自然就强了。
落地层：让代码扩展既有速度又有质量的实战技巧
架构搭好了，还得有落地的“工具箱”，不然光有理论，写代码时还是会乱。我见过不少团队，架构设计得头头是道，但实际开发中为了赶进度，组件里堆业务逻辑，共享代码复制粘贴，结果项目还是越做越臃肿。这部分就分享几个“既能快又能好”的实战技巧，都是我在多个项目里验证过的。
懒加载+预加载：用户体验和开发效率双提升
项目大了，打包出来的 JS 文件可能有几兆甚至十几兆，首屏加载慢得让人想关页面。很多人知道 Angular 有“路由懒加载”，但真正用对的不多。懒加载的核心是“只加载当前需要的模块”，比如用户访问首页时，只加载 HomeModule，点到订单页再加载 OrderModule，这样首屏加载速度能快 60% 以上。
怎么配置懒加载？其实很简单，在路由定义里用 loadChildren 代替 component，比如：
const routes: Routes = [ { path: 'orders', loadChildren: () => import('./order/order.module').then(m => m.OrderModule) }
];
这样 OrderModule 就会被单独打包成一个 JS 文件，只有访问 /orders 时才加载。但光有懒加载还不够，用户第一次点订单页时可能会等几秒加载时间，体验不好。这时候可以用“预加载策略”——在用户浏览首页时，后台偷偷加载后续可能用到的模块。
Angular 自带两种预加载策略：PreloadAllModules（预加载所有懒加载模块）和 NoPreloading（不预加载），但实际项目中这两种都太极端了。我通常会自定义预加载策略，比如只预加载“核心模块”（如用户、订单），或者根据用户行为预测加载。比如那个电商团队，他们发现 80% 的用户会从首页去商品列表页，就自定义了一个 SelectivePreloadingStrategy，只预加载 ProductModule，首屏加载快了，后续页面切换也不用等，用户满意度一下就上来了。
你可以现在打开自己项目的路由配置，看看有没有用懒加载？如果所有模块都在根模块里 imports，赶紧改成懒加载试试。记着用 Angular CLI 的 ng build stats-json 命令生成打包分析文件，用 Webpack Bundle Analyzer 看看哪些模块体积大，优先对这些模块做懒加载，效果更明显。
代码复用：别重复造轮子，用“共享三件套”提效
项目里最浪费时间的就是“重复写同样的代码”——比如每个表单都要写手机号验证，每个列表都要写分页逻辑，改一处得改十几处。这时候你需要“共享三件套”：共享组件、指令、管道，把重复逻辑抽出来，一次编写到处复用。
共享组件就像“乐高积木”，比如全局通用的按钮、弹窗、加载动画，你可以建一个 SharedModule，把这些组件放进去，再用 exports 暴露出来，其他模块引入 SharedModule 就能直接用。我之前帮一个团队做后台系统，他们光“搜索框”组件就重复写了 12 遍，样式还不统一。后来我们抽了个 AppSearchComponent，支持防抖、回车搜索、清除功能，其他模块直接引用，不仅代码量少了 30%，UI 也统一了。
指令和管道可能被你忽略了，但它们是复用“行为逻辑”的神器。比如你想让多个元素支持“点击防抖”（防止用户连续点击），可以写个 DebounceClickDirective；想格式化日期，写个 DateFormatPipe。这些小东西看似简单，积累多了能省大量时间。那个电商团队后来建了个“共享逻辑库”，里面有 20 多个指令和管道，新开发的同事不用再写基础逻辑，直接调用现成的，开发速度快了不少。
下面这个表格是我 的“共享代码检查清单”，你可以对照看看自己的项目有没有做到：
| 复用类型 | 检查点 | 优化方法 |
|---|---|---|
| 共享组件 | 是否有3个以上组件用同样的UI/逻辑？ | 抽成共享组件，通过@Input/@Output传参 |
| 指令 | 是否有元素需要相同的交互行为？ | 写属性指令，封装DOM操作或事件逻辑 |
| 管道 | 是否有重复的数据格式化逻辑？ | 用管道转换数据，如日期、金额格式化 |
你按这个表检查一遍，肯定能发现不少可以复用的代码。我那个朋友的团队，第一次做这个检查时，发现有 7 个地方在重复写“列表空状态”逻辑，后来抽成一个 EmptyStateComponent，光这一个组件就省了 500 多行代码。
其实代码可扩展性说难也不难，核心就是“提前规划边界，少写重复代码”。你不用一下子把所有方法都用上，可以先从模块化拆分和依赖注入做起，再慢慢加入懒加载和共享组件。我见过太多团队因为前期没注意这些，后期重构时花的时间比重新开发还多。
你现在的Angular项目遇到扩展问题了吗？是模块依赖理不清，还是服务太多不好管理？可以在评论区告诉我你的具体情况，我帮你看看可能的优化方向！
你是不是也遇到过这种情况？项目跑了一年多，模块越堆越多，现在打开代码编辑器，想改个订单状态的小逻辑，结果发现用户模块、支付模块都引用了这段代码，改之前得先全局搜一遍谁在用，改完还得提心吊胆测半天，生怕动了哪个隐藏的依赖。这种时候千万别想着“一口吃成胖子”，从头重构到尾，不仅耗时间，还容易出乱子。我 你先从“高频改动模块”下手，就像家里大扫除，先把最乱的客厅收拾干净，其他地方慢慢整理，效果又快又明显。为啥是高频改动模块？因为这些地方每天都在改，问题暴露得最彻底，比如订单模块、用户中心，你改得越多，越清楚哪里耦合最严重，优化完马上就能感受到开发速度变快，测试时间减少，这种“即时反馈”特别能帮你坚持下去。
具体怎么操作呢？第一步先画张“模块依赖图”，不用太复杂，就列列每个模块都引用了哪些其他模块的组件或服务，你会发现有些模块像个“交际花”，谁都依赖它，这种就是重点目标。比如我去年那个电商项目，订单模块被5个其他模块直接引用，改个订单列表接口，购物车、用户中心的页面都可能跟着出问题。然后第二步就是给这些高频模块“分家”，按业务域拆成独立的Feature Module，比如订单模块里只放订单列表、订单详情、订单状态管理这些相关的组件和服务，跟其他模块的通信就通过定义好的“接口”，别让它们直接串门。拆完之后，你会发现每个模块就像有了独立的“围墙”，改订单的逻辑再也不用担心影响购物车了。接着第三步，给模块“瘦身”，看看组件里是不是塞了太多业务逻辑，比如有些组件里调API、处理数据格式化，这些都挪到服务里去，用依赖注入让组件和服务松绑，以后想换个API请求方式，直接改服务就行，组件不用动。最后再给这些模块加上懒加载，访问的时候才加载，首屏速度也能快不少。就像那个电商项目，他们的订单模块每周要改3-5次，拆分优化完第一个月，回归测试时间就少了40%，团队里的小伙伴都说“终于敢放心改代码了”。
模块化按“业务域”拆分时，如何确定业务域的边界？
确定业务域边界可以参考“高内聚低耦合”原则：一个业务域内的组件、服务应围绕同一核心功能（如“用户管理”“订单处理”），且对外仅暴露必要接口。可以从3个角度判断：
小型Angular项目也需要用依赖注入吗？会不会增加复杂度？
即使是小型项目，依赖注入也 从一开始使用。依赖注入看似多写几行代码，但能避免后期“硬编码”导致的重构成本。比如小项目初期直接new服务，后期需要切换API环境或添加日志功能时，需逐个修改组件；而用依赖注入只需在模块providers中替换服务实现，组件无需改动。实际开发中，我见过多个3人以下的小项目，因前期没用依赖注入，半年后扩展支付功能时，花了两周时间重构服务调用逻辑。对小型项目，可先从核心服务（如API请求、用户状态）开始用依赖注入，复杂度低且收益长远。
懒加载会导致首次访问子页面时加载慢吗？如何平衡加载速度和体验？
懒加载确实可能让首次访问子页面时出现短暂加载延迟，但可通过“预加载策略”缓解。Angular支持自定义预加载逻辑，比如：
共享组件设计时，如何避免“过度设计”？什么情况下不适合做共享组件？
避免共享组件过度设计的关键是“按需抽象”，可参考3个判断标准：
项目已经很臃肿，模块依赖混乱，从哪里开始优化最有效？
已有臃肿项目的优化可从“高频改动模块”入手，这类模块通常问题暴露最明显，优化后收益也最高。具体步骤：
