路由这层东西，看着简单，真正用起来全是细节。Angular项目里几乎所有页面跳转、权限控制、模块懒加载都绕不开RouterModule，可很多开发者的认知停留在“配置一个routes数组、模板里放一个router-outlet”就没下文了。这个系列的第一篇，我不打算把官方文档复读一遍，而是专门把RouterModule的配置方式、路由出口的渲染机制这两块核心内容讲透，顺带把实际开发中高发的几个坑列出来。适合刚接触Angular路由的初学者，也适合写过一段时间但遇到“跳转不生效”“白屏”“参数丢”这些问题时没有头绪的开发者。
我做了几年Angular项目，一个直观感受是：路由问题的排查往往比写路由代码更花时间，很多坑的根源都在对RouterModule和router-outlet这两个最基础概念的理解偏差上。所以这一篇讲的都是实打实的东西，从配置到原理，从代码到排查，尽量让读者看完能直接用到项目里。
1. 页面跳转的本质：单页应用里的“前台分发系统”
传统的多页面网站，页面跳转靠浏览器向服务器重新发起请求，服务器返回另一个HTML，整个页面刷新。Angular这类单页应用不一样，应用启动时只会加载一个HTML页面，后端的“页面切换”就交给了前端路由：路由根据URL的变化，决定当前该显示哪个组件，并且不触发整页刷新。打个比方，路由规则就像公司前台的分发表，来访者报出门牌号，前台告诉他去哪个会议室，这个过程不需要把整栋大楼重新改造一遍。
Angular路由由@angular/router包提供，核心入口就是RouterModule这个模块。平时我们写的routes数组、调用的forRoot/forChild、模板里的<router-outlet>，都属于这套体系的不同部分。很多人不理解为什么是“模块”不是“服务”，因为Angular把路由功能设计成了可配置的模块，通过RouterModule把路由配置、指令、服务打包注入到应用里，统一管理。
这个设计带来的直接好处是：路由能力可以被任意模块引入和扩展。根模块拿到的是全局路由服务，特性模块拿到的是挂载在根路由之下的局部路由配置，互不干扰又层级分明。理解了这个分层，后面看forRoot和forChild的区别就不会困惑了。
2. 路由的根基：RouterModule 的正确打开方式
2.1 forRoot 与 forChild：为什么根模块和子模块用法不一样
RouterModule最常被提到的方法就是forRoot()和forChild()。一个典型的根路由配置长这样：
// app-routing.module.ts import { NgModule } from '@angular/core'; import { RouterModule, Routes } from '@angular/router'; const routes: Routes = [ { path: '', redirectTo: '/home', pathMatch: 'full' }, { path: 'home', component: HomeComponent }, { path: 'about', component: AboutComponent } ]; @NgModule({ imports: [RouterModule.forRoot(routes)], exports: [RouterModule] }) export class AppRoutingModule {}而特性模块里的路由配置，比如一个ProductModule，用的是forChild()：
// product-routing.module.ts import { NgModule } from '@angular/core'; import { RouterModule, Routes } from '@angular/router'; import { ProductListComponent } from './product-list.component'; import { ProductDetailComponent } from './product-detail.component'; const routes: Routes = [ { path: 'products', component: ProductListComponent }, { path: 'products/:id', component: ProductDetailComponent } ]; @NgModule({ imports: [RouterModule.forChild(routes)], exports: [RouterModule] }) export class ProductRoutingModule {}为什么根模块必须用forRoot，子模块必须用forChild？原因是forRoot会创建全局唯一的Router服务实例，并且在应用启动时执行初始导航；forChild只做一件事——把新的路由配置合并到现有的路由表中，不会重复创建Router服务。
| 对比项 | RouterModule.forRoot() | RouterModule.forChild() |
|---|---|---|
| 使用位置 | 根模块（AppModule） | 特性模块（如商品、订单模块） |
| 创建Router服务 | 创建全局唯一实例 | 不创建，复用已有实例 |
| 可配置全局参数 | 支持（如enableTracing、useHash） | 不支持 |
| 路由合并方式 | 初始化路由表 | 追加到已有路由表 |
| 重复调用后果 | 多次调用会创建多个Router实例，报错或行为异常 | 可以多次调用，但要注意路由路径冲突 |
实际项目中一个高频翻车点就是：有人图省事，在懒加载的子模块里也用了forRoot，结果启动后控制台直接报错，说Router已被实例化。所以记住一句话：全应用只能有一个forRoot，其余地方都交给forChild。如果开发的是库项目，自身模块的路由配置同样用forChild，因为最终消费方会在根模块调forRoot。
2.2 路由表怎么写才不踩坑：核心配置项逐个拆解
Routes数组是路由的核心配置，每个元素叫Route。我挑几个影响面最大、最容易出问题的配置项，逐个拆解。
先说path和component。path是URL路径片段，component是对应要渲染的组件。这里有个新手必踩的坑：path里不能以/开头，除非是空字符串''。因为path表示的是“相对于当前路由层的路径片段”，子路由的path会自动拼接在父路由的path后面。如果写了/home，Angular会把路径解析成绝对路径，导致匹配异常。
然后是redirectTo和pathMatch。重定向常常被误解。{ path: '', redirectTo: '/home', pathMatch: 'full' }这个配置里，pathMatch: 'full'表示必须整个路径完全匹配空字符串才重定向。如果没有写pathMatch或者写成prefix，那''会作为任意路径的前缀去匹配，结果就是所有路径都命中这个重定向，页面永远停在/home，其余路由全部失效。我见过不止一个同事因为这个把整个路由表“劫持”了。
通配符**也很关键，一般放在路由表末尾做404兜底：
{ path: '**', component: NotFoundComponent }**能匹配任意路径，所以必须放在最后。放在前面的后果是它优先命中，后面所有路由都匹配不到了。这里有一个很多人忽略的细节：Angular的路由匹配默认按Routes数组的声明顺序进行，第一个匹配到的生效，而不是“最精确的生效”。理解了这一点，很多“为什么我的路由不生效”的排查就会快很多。
children用于配置嵌套路由，loadChildren用于懒加载，canActivate等守卫用于权限控制。第二篇系列里我会专门讲守卫和懒加载，这篇先把基本配置和匹配顺序吃透。有一点值得现在提出来：loadChildren接收一个函数，函数返回import()动态导入的模块，这个写法替代了早期Angular版本里传字符串路径的写法，类型安全并且支持更好的代码分割。
3. 路由出口：页面组件究竟渲染到哪里
3.1 router-outlet 的工作原理
配置了路由表之后，组件显示在哪里？答案是<router-outlet>。这个指令在模板中占据一个位置，Angular会根据当前激活的路由，把对应的组件动态渲染到这个位置里。
工作流程是这样的：路由匹配到某个Route后，Angular会取得该路由关联的组件类型，然后用ComponentFactoryResolver动态创建组件实例，再把它挂载到router-outlet对应的ViewContainerRef上。路由切换时，旧的组件会被销毁，新的组件被创建，整个过程发生在同一个出口位置。
这里有一个非常关键的认知：router-outlet不是“把整个页面换掉”的魔法，它只是应用组件树里的一个替代节点。如果你的根组件模板里写了<router-outlet></router-outlet>，那所有路由组件都会渲染在这个标签的位置。父组件和它的布局（侧边栏、顶部导航）会一直保留，只有出口区域的内容在变化。所以Angular应用里常见的设计是：根组件只放一个出口，所有页面的公共布局放外层组件，内部再嵌套出口，实现局部刷新。
看一个最简单也最常见的根组件模板：
<!-- app.component.html --> <div class="app-layout"> <app-navbar></app-navbar> <main class="content"> <router-outlet></router-outlet> </main> </div>导航栏是公共的，路由组件渲染在router-outlet的位置。所有页面切换都只替换main内部的部分，导航栏不重新渲染，这是单页应用体验好的关键原因之一。
3.2 命名出口与辅助路由
router-outlet支持name属性，未命名的是默认出口，命名出口可以同时渲染多个路由组件。这个机制是辅助路由（auxiliary routes）的基础。
命名出口的配置方式是在路由表里指定outlet：
const routes: Routes = [ { path: 'chat', component: ChatComponent, outlet: 'sidebar' } ];模板里有多个出口：
<router-outlet></router-outlet> <router-outlet name="sidebar"></router-outlet>导航时指定出口名称：
<a [routerLink]="[{ outlets: { sidebar: ['chat'] } }]">打开聊天</a>这个能力适合做“侧边栏独立于主页面内容”的场景，比如聊天窗口、购物车抽屉、消息中心。实际开发里用命名出口的频率不算高，但遇到时需要能马上上手。一个常见的坑是：命名出口路由激活后，URL里会带上(sidebar:chat)这样的片段，如果对这个格式不熟悉，排查时会误以为路由写错了。
4. 页面跳转实操：从创建项目到传参回显
4.1 搭建最小可运行案例
理论知识讲完，直接跑一个完整案例。我用Angular CLI创建项目，然后一步步把路由配置、出口、页面跳转串起来。
先创建一个新项目，--routing参数会让CLI自动生成带路由模块的骨架：
ng new router-demo --routing生成的项目里默认有app-routing.module.ts和app.module.ts。打开app-routing.module.ts，默认只有一行空路由：
const routes: Routes = [];接下来创建几个页面组件。我做了HomeComponent、AboutComponent和ProductComponent三个页面，其中ProductComponent接收一个id参数，模拟详情页：
ng generate component home ng generate component about ng generate component product然后配置路由表：
// app-routing.module.ts import { NgModule } from '@angular/core'; import { RouterModule, Routes } from '@angular/router'; import { HomeComponent } from './home/home.component'; import { AboutComponent } from './about/about.component'; import { ProductComponent } from './product/product.component'; const routes: Routes = [ { path: '', redirectTo: '/home', pathMatch: 'full' }, { path: 'home', component: HomeComponent }, { path: 'about', component: AboutComponent }, { path: 'product/:id', component: ProductComponent }, { path: '**', redirectTo: '/home' } ]; @NgModule({ imports: [RouterModule.forRoot(routes)], exports: [RouterModule] }) export class AppRoutingModule {}根模板里放出口：
<!-- app.component.html --> <h1>路由示例</h1> <nav> <a routerLink="/home" routerLinkActive="active">首页</a> <a routerLink="/about" routerLinkActive="active">关于</a> </nav> <router-outlet></router-outlet>4.2 模板跳转与编程式导航
Angular里跳转有两种方式：模板中用routerLink指令，组件类中用Router服务。
routerLink的常见写法有这么几种：
<!-- 绝对路径跳转 --> <a routerLink="/home">首页</a> <!-- 相对路径跳转，当前路径是 /product/123，跳转到 /product/123/detail --> <a routerLink="detail">详情</a> <a routerLink="../list">返回列表</a> <!-- 带参数的跳转 --> <a [routerLink]="['/product', productId]">商品详情</a> <!-- 带查询参数的跳转 --> <a [routerLink]="['/about']" [queryParams]="{ from: 'home' }">关于（带来源参数）</a>routerLinkActive用于给当前激活的导航项加样式，接收一个CSS类名。它的工作逻辑是：当路由匹配到该链接指向的路径时，把类名加到元素上。实际项目里做顶部tab高亮，基本人手一个。
编程式导航用Router服务：
import { Router } from '@angular/router'; constructor(private router: Router) {} goToProduct(id: number): void { this.router.navigate(['/product', id]); } goBack(): void { this.router.navigate(['../'], { relativeTo: this.route }); }navigate方法的第一个参数是路径片段数组，第二个参数可以传relativeTo、queryParams、replaceUrl等选项。这里有一个很多人搞混的点：navigate返回的是Promise<boolean>，真正跳转是异步的，不要在调用后立刻读取路由状态，容易拿到旧值。
4.3 路由参数：path参数、查询参数、参数订阅
详情页按/product/:id配置后，组件里拿参数有两条路：快照snapshot和订阅paramMap。
import { Component, OnInit } from '@angular/core'; import { ActivatedRoute } from '@angular/router'; @Component({ selector: 'app-product', template: `<p>当前商品ID：{{ productId }}</p>` }) export class ProductComponent implements OnInit { productId: string = ''; constructor(private route: ActivatedRoute) {} ngOnInit(): void { // 快照方式：适合组件只创建一次、参数不变的情况 this.productId = this.route.snapshot.paramMap.get('id'); // 订阅方式：同一组件实例复用而参数变化时，必须用订阅 this.route.paramMap.subscribe((params) => { this.productId = params.get('id') ?? ''; }); } }初学者很容易忽略快照和订阅的差异。场景是这样的：如果从/product/1跳转到/product/2，Angular会复用ProductComponent的组件实例，不会重新走一遍ngOnInit。如果用snapshot取值，第二次跳转后页面显示的仍然是旧的1。这时候必须用subscribe订阅paramMap，在回调里更新数据。
注意：
subscribe记得在ngOnDestroy里取消订阅，或者用takeUntilDestroyed之类的操作符，否则会有内存泄漏风险。这是Angular开发者面试常考题，也是实际项目里的高频隐患。
查询参数的读取方式类似，只是换成了queryParamMap。有些场景下需要同时监听路径参数和查询参数的变化，可以用this.route.params和this.route.queryParams，但注意它们都是Observable，每次跳转会发出新值，一定要处理好订阅生命周期。
5. 高发问题排查实录：这些坑我基本都踩过
5.1 路由配置了却白屏
场景：routes数组配置好了，router-outlet也放了，但页面一片空白，控制台也没有明显报错。
排查顺序基本是固定的：先看根模块有没有正确引入AppRoutingModule。CLI生成的项目里AppModule的imports数组应该包含AppRoutingModule，如果不是CLI生成，很多人会漏掉这一步。然后再看路由表里的组件有没有在declarations里声明并导入对应模块。再然后检查router-outlet是不是放在了预期位置，有时组件名字写错或者出口放在了别的地方，内容渲染到了别处。
一个隐蔽的原因是：根组件模板里如果用<router-outlet />这种自闭合写法，可能会在部分场景下解析异常。Angular模板中建议写成成对的<router-outlet></router-outlet>，避免不必要的兼容性问题。
5.2 通配符和空路径的匹配陷阱
前文提过，通配符必须放最后。我再补充一个真实场景：路由表里有{ path: '**', redirectTo: '/home' }，结果用户访问/product/999时居然没有进入详情页，而是被重定向到了首页。原因就是通配符放在了/product/:id的前面。
排查时建议在路由表顶部加一个临时排查项：
{ path: '**', component: DebugComponent } // 临时用于排查，正常项目放末尾如果加上这个之后所有页面都显示DebugComponent，说明前面某条路由的匹配优先级压过了你的预期，逐条检查path写法。这个排查法在复杂路由表里尤其好用。
还有一个场景：配置了{ path: 'home', component: HomeComponent }，但访问/时直接白屏。原因是没有处理空路径。要么给空路径配置组件，要么重定向到明确的路由：
{ path: '', redirectTo: '/home', pathMatch: 'full' }记住了，凡是redirectTo，pathMatch写full最保险，尤其目标路径是另一个有具体路径的路由时。
5.3 刷新页面404与跳转后组件不刷新
刷新404不是Angular本身的问题，而是静态资源服务器的配置问题。典型场景：部署Nginx或类似静态服务器时，服务器找不到/product/123对应的物理文件，返回404。常规做法是把所有未匹配的路径重写到index.html，Angular路由接管后再做前端匹配。这个配置和部署环境强相关，但如果你在本地开发时用ng serve从未遇到过404，上线后出现了，基本就是这个原因。
跳转后组件不刷新这个问题，我在前面的4.3小节里已经讲了原因和解法。这里再补一个现象：从列表页跳转到详情页，详情页依赖ngOnInit里的一次性加载，第二次进入详情页不触发ngOnInit，数据没刷新。这也是同一个根因——路由参数变了，组件实例没变。解法还是订阅paramMap，在回调里重新加载数据。
下面是几个高频问题速查表：
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 访问根路径白屏 | 空路径未配置或未重定向 | 检查path: ''和pathMatch |
| 所有路径都被重定向首页 | 通配符或空路径放在路由表前面 | 调整路由表顺序，兜底放最后 |
| 详情页参数不更新 | 使用了snapshot.paramMap | 改为订阅paramMap |
| 子模块路由不生效 | 模块未用forChild或未在父模块imports | 检查RouterModule.forChild |
| 页面刷新后404 | 静态服务器未重写到index.html | 部署层面配置try_files |
| 控制台报Router重复实例化 | 多于一个forRoot | 全局只保留根模块的forRoot |
| 路由跳转后滚动条不在顶部 | Angular默认保持滚动位置 | 路由配置设置scrollPositionRestoration: 'enabled' |
scrollPositionRestoration这个配置值得展开一下，很多项目都遇到过“从详情页返回列表页，滚动条还停在之前的位置”这种体验问题。在forRoot的第二个参数里配置：
RouterModule.forRoot(routes, { scrollPositionRestoration: 'enabled', anchorScrolling: 'enabled' })forRoot实际上可以接收一个额外的ExtraOptions配置对象，除了滚动位置恢复，还有useHash、enableTracing等选项。useHash用于兼容不支持HTML5 History模式的服务器环境，URL里会出现#号。enableTracing打开后会在控制台输出路由事件日志，排查路由生命周期问题时非常好用，生产环境记得关掉。
6. 留下一个钩子：路由体系还有哪些进阶玩法
第一篇把最核心的RouterModule配置和router-outlet出口机制讲完了，但Angular Router这套体系远不止这些。我在实际项目里用得比较多的还有路由守卫、懒加载、预加载策略，以及路由事件机制。尤其是可用性要求高的应用，CanActivate、CanDeactivate、Resolve这组守卫组合决定了整个应用的权限骨架和数据预取方式，值得单独开一篇详细聊。
还有一个推荐做法：在项目初期就约定统一的路由命名规范和模块划分方式。比如所有业务模块对应一个路由模块，路由的path与模块名一一对应，守卫统一放在独立的守卫目录。这样后续做权限调整、懒加载拆分时，改动面会小很多。我自己接手过几个路由配置全部堆在一个文件里的老项目，维护成本非常高，后来都是分批拆成模块路由才算救回来。
最后分享一个个人习惯：每次配置路由表，我都会额外关注两点——通配符的位置和空路径的pathMatch。这两个看似不起眼的配置，引起的故障基本都是全站级别的。写配置时多花十秒钟检查，排查时少花两小时定位。
