Angular CLI 标准化脚手架

要解决的具体问题

团队里跑着多个 Angular 项目时，常会出现这样的混乱：

• 有人生成组件时把 .spec.ts 随手丢在根目录，有人直接省略测试文件
• 服务层的目录结构今天叫 shared/services，下周又变成 core/services
• 新人入职后，光是记住「组件要建在哪、测试文件怎么命名」就要问三四个同事
• 更棘手的是，本地跑通的功能，换到 CI 环境就因为命令不一致而失败

这些问题的根源不是开发者能力不足，而是没有把团队约定固化成可执行的规则。靠文档约定会过期，靠口口相传会失真，只有让工具替人做决定，才能从根上消除差异。

技能如何工作

这个技能的核心逻辑是「用 Angular CLI 把团队约定变成生成规则」，关键步骤分为四步：

1. 标准化初始化项目

通过 ng new 创建项目时，强制启用测试和 lint 配置，生成的目录结构直接符合团队标准。不需要手动调整 angular.json 里的路径，CLI 会按预设规则把 src/app、src/environments 等目录安排妥当。

1. 按约定生成组件与服务

调用 ng generate component 或 ng generate service 时，技能会确保生成的文件名、测试文件位置完全统一。比如生成 user-profile 组件，会自动创建：

• src/app/user-profile/user-profile.component.ts
• src/app/user-profile/user-profile.component.spec.ts
• src/app/user-profile/user-profile.component.html

不再需要开发者手动新建文件或猜测该放哪。

1. 用 Schematics 固化定制模板

当团队有特殊需求时（比如组件必须带 standalone: true），技能会把这些规则写进 schematics 模板。新人执行 ng generate 时，CLI 会直接套用这些规则，生成的代码天然符合团队规范，不需要额外修改。

1. 统一 CI 与本地流程

技能会确保本地的 ng build、ng test 命令和 CI 环境完全一致，避免因 Node 版本、依赖安装方式不同导致的构建差异。

适用边界与注意点

这个技能最适合中大型 Angular 团队——当项目里超过 5 个开发者、需要维护多个模块时，标准化脚手架的价值才会显现。小团队或个人项目可能觉得「自己记一下约定就行」，但一旦团队规模扩大，这种「靠记忆」的方式必然会出问题。

使用时要特别注意：

• 不要绕过 CLI 手动创建文件。偶尔手写一次可能没问题，但积累下来会导致目录结构逐渐偏离标准。
• Schematics 模板需要定期维护。如果团队规范变了（比如从 Component 改成 Standalone Component），必须同步更新 schematics，否则新生成的文件还是会用过时的模板。
• CLI 版本要与 Angular 版本严格匹配。升级 Angular 大版本时，CLI 也要同步升级，否则生成的代码可能不兼容。

对于刚接触 Angular 的开发者，这个技能能帮你快速建立「用工具管理项目结构」的习惯；对于老手，它能把团队积累的最佳实践固化下来，避免重复踩坑。本质上，这是一个用自动化消除人为差异的过程，让代码结构像工厂流水线一样稳定可靠。