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，导致包体积失控。正确写法是字符串形式：
立即学习“Java免费学习笔记（深入）”；
本书是全面讲述PHP与MySQL的经典之作，书中不但全面介绍了两种技术的核心特性，还讲解了如何高效地结合这两种技术构建健壮的数据驱动的应用程序。本书涵盖了两种技术新版本中出现的最新特性，书中大量实际的示例和深入的分析均来自于作者在这方面多年的专业经验，可用于解决开发者在实际中所面临的各种挑战。 本书内容全面深入，适合各层次PHP和MySQL开发人员阅读，既是优秀的学习教程，也可用作参考手册。
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 应用最难的从来不是功能实现，而是模块拆分后依赖关系是否可预测、服务生命周期是否可控、懒加载是否真正生效。这些地方一旦出问题，调试成本远高于写业务逻辑本身。
