Angular是基于TypeScript的前端框架而非JavaScript本身，其大型应用开发关键在于理解约束边界、模块逻辑与依赖注入；必须用ng generate创建文件以避免装饰器遗漏、模块未注册等问题；路由forRoot()/forChild()控制单例权，HttpClientModule.forRoot()等仅根模块调用一次；懒加载须用字符串或合规函数式loadChildren写法；服务生命周期由provideIn配置决定，非仅@Injectable()声明。
Angular 不是 JavaScript 的一个“是什么”，而是基于 TypeScript 构建的前端框架，它本身不等于 JavaScript，但运行在 JavaScript 引擎上。想用 Angular 构建大型应用，关键不在“学完教程”，而在理解它的约束边界、模块组织逻辑和依赖注入的实际落地方式。
Angular 项目结构为什么必须用 ng generate 而不是手动创建文件
手动新建 component 或 service 文件容易漏掉三件事：装饰器未声明、未注册到模块、路径未被 tsconfig.json 包含。Angular CLI 的 ng generate component user-list 会同步生成 .ts、.html、.scss、.spec.ts，并在对应 NgModule 的 declarations 中自动注册——这对大型项目中组件复用和测试覆盖率至关重要。
- 不使用
ng generate，ng build --prod可能报Component 'X' is
not included in a module
- 自定义路径别名（如
@app/core）依赖 CLI 自动生成的paths配置，手动建文件后需手动补全tsconfig.json - IDE（如 VS Code）对
TemplateRef、ViewContainerRef等类型的跳转支持，依赖 CLI 创建时的类型声明完整性
forRoot() 和 forChild() 的区别不是“根模块才用”，而是“单例控制权在哪”
比如 RouterModule.forRoot(routes) 在根模块调用，会提供全局路由服务实例；而 RouterModule.forChild(routes) 仅在特性模块内注册子路由，不覆盖根路由服务。如果在多个特性模块都误用 forRoot()，会导致 Router 实例重复创建，引发导航状态错乱或内存泄漏。
-
HttpClientModule.forRoot()同理：只应在根模块调用一次，否则拦截器可能执行多次 -
StoreModule.forRoot()（NgRx）也一样，多调用会覆盖 store 状态树结构 - 第三方库文档里写 “call forRoot() in AppModule” 是硬性约束，不是建议
懒加载模块（Lazy Load）的路由配置必须用 loadChildren 字符串语法，不能用函数导入
Webpack 的代码分割能力依赖静态分析。如果写成 loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule)，开发时能跑，但生产构建可能无法生成独立 chunk，导致包体积失控。正确写法是字符串形式：
const routes: Routes = [
{
path: 'admin',
loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule)
}
];
注意：Angular 14+ 支持函数式写法，但前提是启用 buildOptimizer: true 且 optimization: true，否则仍会退化为全量打包。
- 字符串写法（旧式）：
loadChildren: './admin/admin.module#AdminModule'已废弃，Angular 8+ 不再识别 - 函数式写法必须配合
angular.json中的"aot": true，否则 JIT 编译下无法解析动态 import - 检查是否生效：构建后查看
dist/目录是否有admin-*.js这类独立文件
服务（Service）的提供方式决定它的生命周期，不是“写了 @Injectable() 就能跨模块共享”
默认情况下，@Injectable({ providedIn: 'root' }) 表示该服务由根注入器提供，整个应用单例；但如果在某个 NgModule 的 providers 数组里声明，那它只在该模块及其子模块中有效——这对大型应用的状态隔离很关键。
- 用户权限服务（
AuthService）适合providedIn: 'root' - 表单校验服务（
FormValidatorService）若只在特定特性模块用，应放在该模块的providers里，避免污染全局 injector - 用
providedIn: 'any'会导致每个注入该服务的组件都获得新实例，易引发状态不一致
大型 Angular 应用最难的从来不是功能实现，而是模块拆分后依赖关系是否可预测、服务生命周期是否可控、懒加载是否真正生效。这些地方一旦出问题，调试成本远高于写业务逻辑本身。
