企业官网建设流程全解析

1. main.ts 里那两行 import：启动代码为什么版本之间不一样

1.1 你在脚手架里天天见的两种入口

每个用脚手架创建过 Angular 项目的人，应该都见过 main.ts 里这两行代码：

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic'; platformBrowserDynamic() .bootstrapModule(AppModule) .catch(err => console.error(err));

我指的是现代 Angular，也就是 Angular 2 之后的版本，不是 AngularJS。如果你新建的项目用的是 Standalone Component，入口又会变成这样：

import { bootstrapApplication } from '@angular/platform-browser'; import { appConfig } from './app/app.config'; import { AppComponent } from './app/app.component'; bootstrapApplication(AppComponent, appConfig) .catch((err) => console.error(err));

同样是启动应用，一个从@angular/platform-browser-dynamic里拿方法，一个从@angular/platform-browser里拿方法。如果不看文档，很容易把这两个包当成同一件事的两种写法。它们真正的分工是：@angular/platform-browser负责浏览器运行时，@angular/platform-browser-dynamic负责在浏览器里做 JIT 即时编译。两个包一前一后，回答了 Angular 应用"怎么在浏览器里跑起来"这个问题的两个阶段。

1.2 从 JIT 时代到 AOT 时代，入口方法为什么没跟着变

Angular 2 到 Angular 8 那段时间，CLI 生成的项目 main.ts 统一是platformBrowserDynamic().bootstrapModule(AppModule)。开发时用 JIT，模板字符串在浏览器里编译；生产构建时则用 AOT，提前把模板编译成静态代码。但生产构建的入口代码和开发模式长得一模一样，都是platformBrowserDynamic()，因为构建器会在后台处理掉编译差异。

Angular 9 之后 Ivy 成为默认编译器，AOT 逐渐成为默认策略，Standalone 组件稳定后又出现了bootstrapApplication。可很多老项目的 main.ts 还是platformBrowserDynamic()。这就造成了一个局面：入口函数名没变，但背后的编译策略早就变了。你在源码里看到什么入口，并不直接等于项目用了什么编译策略。

1.3 记住一条主线：一个管运行，一个管先编译再运行

如果只记一句话，那就是：@angular/platform-browser是 Angular 应用在浏览器里运行的运行时包，@angular/platform-browser-dynamic是让浏览器拥有 JIT 编译能力的入口包。前者回答"怎么运行"，后者回答"怎么编译"。两者不是平行的两个选择，而是叠加关系——动态编译平台建立在浏览器平台之上，先拿到编译能力，再完成启动。

往深里看，这两个包牵出了 Angular 整个平台抽象设计和编译器架构。下面我把这条线完整拆开。

2. Angular 为什么要专门做一个"平台层"

2.1 平台是宿主环境适配层，不是操作系统那个平台

Angular 里提到 platform，很多人第一反应是 Windows、Linux 这类的平台。实际上 Angular 的 PlatformRef 指的是"宿主环境的适配层"。浏览器、服务端 Node.js、Web Worker，这些环境的底层 API 完全不同：浏览器有document、window，服务端没有；Node 里有文件系统，浏览器没有。Angular 不可能针对每个环境写一套应用代码，所以它在应用和宿主之间插入了一层 platform。

这一层负责提供平台级服务，管理平台注入器，并决定应用最终用什么方式渲染。platformBrowser()创建的就是浏览器平台的实例，platformServer()创建服务端平台实例，Web Worker 场景还有专门平台。应用代码不直接碰document，而是通过平台提供的抽象服务去操作。

2.2 platform-browser 是浏览器宿主的最小运行时集合

@angular/platform-browser的核心职责，是把 Angular 应用接到浏览器这个宿主上。它内部注册了一大批浏览器专用 Provider，比如DomRendererFactory2、EventManager、DomSanitizer、TransferState等。这些服务合起来构成了"Angular 应用在浏览器里跑起来所需要的最小环境"。

可以这么理解：platform-browser相当于把浏览器环境里那些乱七八糟的 API 整理成 Angular 认识的一整套服务接口。组件代码里写的[class.active]、(click)、{{ value }}，到了运行时都要通过这些服务真正落到 DOM 上。没有这一层，Angular 的组件系统就失去了和浏览器打交道的通道。

2.3 平台工厂的嵌套：core、browser、browserDynamic

Angular 的平台不是一块铁板，它由底层基础平台逐层叠加而来。底层是@angular/core里的核心平台，然后是浏览器平台，再往上才是动态编译平台。createPlatformFactory这个工具函数就是用来做这种叠加的。

platformBrowser()大致可以理解为：基于核心平台，叠加浏览器专属 Provider，生成一个浏览器平台工厂；platformBrowserDynamic()则在浏览器平台的基础上，再叠加 JIT 编译器相关 Provider，生成一个带编译能力的平台工厂。所以platform-browser-dynamic天然包含platform-browser的能力，这也是为什么 JIT 入口也能跑通大部分应用流程。

用依赖方向来看：

• @angular/core：核心 DI、组件系统、应用启动机制
• @angular/compiler：模板编译器，本身不依赖浏览器
• @angular/platform-browser：浏览器运行时，依赖 core，不依赖 compiler
• @angular/platform-browser-dynamic：浏览器 JIT 编译入口，同时依赖 browser 和 compiler

2.4 一个页面只能有一个 Angular 平台

PlatformRef 是全局单例，同一个页面里用createPlatform或平台工厂创建过一次之后，再调用会复用已有实例。这点平时不太容易感知，但如果你在同一个页面里手动调了两次platformBrowserDynamic()，大概率会遇到奇怪的服务状态问题。

我在一个微前端项目里踩过这个坑。子应用挂载时调了一次platformBrowserDynamic()，卸载时想清理又调了一次，结果本来应该独立的应用实例复用了同一个平台注入器，导致服务状态互相污染。后来改成在整体启动流程里只创建一次平台，各子应用各自处理自己的 NgModuleRef，问题才消失。理解平台的单例特性，排查这类问题会快很多。

3. 浏览器运行时到底在替开发者管哪些脏活累活

3.1 从模板到 DOM：Renderer2 与 DomRendererFactory2 的分工

Angular 组件模板不会直接生成一段innerHTML扔进页面。它在运行时通过渲染器来创建、修改、删除 DOM 节点。platform-browser提供了DomRendererFactory2，为每个视图创建对应的Renderer2实例。你在自定义指令里写renderer.setStyle()、renderer.listen()，用的就是这个服务。

import { Directive, ElementRef, Renderer2, AfterViewInit } from '@angular/core'; @Directive({ selector: '[appHighlight]' }) export class HighlightDirective implements AfterViewInit { constructor(private elementRef: ElementRef, private renderer: Renderer2) {} ngAfterViewInit(): void { this.renderer.setStyle(this.elementRef.nativeElement, 'background', '#fdf6e3'); } }

这里有个容易被忽略的点：直接操作elementRef.nativeElement和通过renderer操作，虽然最终结果一样，但意义不同。直接操作 nativeElement 就把代码绑死在浏览器环境里；通过Renderer2，Angular 可以在 SSR、Web Worker 等场景切换不同渲染器实现，而你的指令代码不用改。这就是运行时抽象层的价值。

样式封装也由渲染管线处理。默认的 ViewEncapsulation.Emulated 模式，Angular 会给组件模板里的元素加上_ngcontent-xxx之类的属性，再生成带属性选择器的样式规则。这套逻辑同样在运行时由渲染器完成，对组件代码透明。

3.2 BrowserModule 不只给根模块"刷存在感"

BrowserModule从@angular/platform-browser导出，是根模块才应该 import 的模块。它内部导出CommonModule和ApplicationModule，并提供ApplicationRef、DomSanitizer、EventManager、TransferState等一批关键服务。

DomSanitizer是个典型例子。你用[innerHTML]绑一段 HTML 内容，Angular 运行时不会直接塞进去，而是先经过安全审查。平台层把这个安全检查放在运行时，是因为最终面对的是真实的浏览器 DOM，安全边界只能在运行时执行。

3.3 组件里感受不到的边界：浏览器 API 还是 Angular 封装

写组件时，模板里的*ngFor、[class]、(click)看起来像魔法。它们其实都走了一套平台提供的运行时机制：事件通过EventManager统一注册，属性绑定通过渲染器写入，变更检测由ApplicationRef驱动。你很少直接感知到这些服务的存在，但它们一直在底层运转。

一个比较有体感的场景是 SSR。组件里如果直接写if (window) ...，服务端渲染阶段会因为找不到window直接报错。但如果你把"读取窗口宽度"这类操作封装成服务，并让服务通过 Angular 的PLATFORM_ID判断当前环境，代码就能在浏览器和服务端都能跑。这就是运行时抽象在真实项目里的价值。platform-browser做的事情，正是把浏览器 API 变成可替换的 Angular 服务，让应用代码不直接依赖某个具体宿主。

3.4 为什么运行时包不能顺手把编译器也带上

一个很自然的疑问：既然platform-browser已经管了这么多运行时的事，为什么不能把 JIT 编译器也塞进去，省得搞出两个包？

原因很简单：体积。Angular 的编译器代码量非常可观，一旦platform-browser依赖它，任何基于platform-browser的应用都没法通过 tree-shaking 把它去掉。AOT 编译的核心收益之一就是运行时不需要编译器，产物体积能大幅下降。如果为了省事把编译器和运行时绑死，等于把 AOT 最大的优势直接废掉。

还有一层原因：编译器本身不依赖浏览器。@angular/compiler在 Node 环境也能运行，AOT 构建就是在构建机上调用它把模板提前编译好。浏览器运行时只需要消费编译产物，没必要在浏览器里维护一份编译器。独立成包，各端按需引入，才是合理的架构。

4. platform-browser-dynamic 那头：JIT 编译器是怎么在浏览器里工作的

4.1 动态编译平台到底给平台加了什么料

platformBrowserDynamic()创建的不仅是一个浏览器平台，还在平台注入器里注册了编译器相关 Provider。核心的有CompilerFactory、JIT 编译器实例、以及编译器需要的资源加载器等。这些 Provider 让平台具备了"在浏览器里现场读取装饰器元数据、现场编译模板"的能力。

代码层面可以大致理解成这样：

import { createPlatformFactory, platformCore } from '@angular/core'; import { COMPILER_OPTIONS, CompilerFactory } from '@angular/core'; export const platformBrowserDynamic = createPlatformFactory( platformBrowser, 'browserDynamic', [ // 提供 JIT 编译器实例 { provide: CompilerFactory, ... }, // 全局编译选项 { provide: COMPILER_OPTIONS, ... }, ] );

虽然真实源码比这复杂，但结构就是"在浏览器平台之上追加编译能力"。所以platform-browser-dynamic不是platform-browser的替代品，而是它的增强版本，专门服务那些需要在运行时进行编译的场景。

4.2 一次 bootstrapModule 调用，浏览器里发生了什么

当你调用platformBrowserDynamic().bootstrapModule(AppModule)时，流程大致是：

1. 平台注入器取出CompilerFactory，创建 JIT 编译器
2. 编译器读取AppModule的@NgModule元数据，分析它依赖了哪些组件、指令、管道
3. 把组件模板字符串编译成可执行的视图定义代码
4. 创建模块实例和注入器，初始化应用
5. ApplicationRef启动根组件，渲染到浏览器 DOM

这个流程最耗时的就是第 3 步。模板编译是 CPU 密集型操作，而且发生在用户打开页面之后。JIT 模式下首屏启动慢，根本原因就在这里。开发时 JIT 有它的优势——改一行模板代码，浏览器重新编译一次，不需要完整重新构建；生产环境这种开销就很难接受了。

4.3 AOT 如何绕过这套编译流程

AOT 构建把第 3 步挪到了构建阶段。@angular/compiler-cli里的 ngtsc 在编译.ts文件时，直接读取模板字符串，产出 Ivy 指令格式的代码。你写的是{{ value }}，构建产物里直接就是ɵɵtextInterpolate这类指令调用。浏览器运行的时候，组件已经是一个"编译好的定义"，不再需要编译器介入。

在 View Engine 时代，AOT 入口更直观，那时候有显式的模块工厂：

import { platformBrowser } from '@angular/platform-browser'; import { AppModuleNgFactory } from './app/app.module.ngfactory'; platformBrowser().bootstrapModuleFactory(AppModuleNgFactory);

bootstrapModuleFactory接收的AppModuleNgFactory就是ngc预先编译产物。这段代码现在很少见了，因为 Ivy 之后不再生成.ngfactory.ts文件，但它非常好地说明了"预先编译好再启动"和"启动时现编译再启动"的区别。理解了它，再看现在的bootstrapApplication，逻辑就通了。

4.4 没有 JIT 包时，典型报错长什么样

动态编译依赖@angular/compiler。如果构建产物里没有编译器，但运行时又真的去编译了某个组件，Angular 会抛出类似这样的错误：

Angular JIT compilation failed: '@angular/compiler' not loaded!

我在排查一个老项目时第一次见到这个报错。当时我们的 main.ts 是标准的platformBrowserDynamic().bootstrapModule(AppModule)，但构建配置里明确开了 AOT。按道理不应该触发 JIT，结果有个第三方库的动态组件在运行时注册了未编译的模板，硬生生把 JIT 路径拉起来了。

这个报错是"平台与编译策略不匹配"最典型的信号。排查方向不是急着换入口函数，而是找到"哪个组件在运行时进入了 JIT 编译路径"。可能的原因包括：模板字符串在运行时拼装、某些动态组件定义不完整、第三方库携带了未编译的装饰器元数据。理解了编译策略的分工，这类问题才不会一头雾水。

5. Ivy 与 Angular 9 之后：分工被重新画了一次

5.1 从 View Engine 到 Ivy，编译产物形态完全不同

Angular 9 之前是 View Engine，AOT 构建会生成辅助工厂文件，模板的编译结果和组件类定义分离。Ivy 之后，编译器把编译结果直接内联到组件类的静态字段上，通过ɵcmp这样的属性挂载。运行时拿到组件类，就拿到了完整的编译信息，不需要额外查找工厂文件。

这个变化让"分离编译器"这件事变得更加彻底。View Engine 时代，平台、编译器、渲染器之间纠缠很多；Ivy 时代，渲染路径被大幅简化，编译产物更扁平，platform-browser和@angular/compiler之间的耦合被进一步切断。这也是为什么 Angular 官方敢在文档里说，AOT 产物在运行时不需要编译器。

5.2 bootstrapApplication 的登场意味着什么

Standalone Component 稳定之后，CLI 新项目的 main.ts 变成了bootstrapApplication(AppComponent, appConfig)。注意这个函数来自@angular/platform-browser，而不是@angular/platform-browser-dynamic。它默认面向已经完成 AOT 编译的代码，内部创建一个浏览器平台，直接启动根组件。

这是一个信号：在现代 Angular 里，platform-browser就是那个正常的启动入口，platform-browser-dynamic更像是兼容模式和特殊场景的工具。bootstrapApplication的设计思路和 JIT 完全解耦，它不假设代码里还有未编译的装饰器元数据需要现场翻译。

5.3 现在还需要 platform-browser-dynamic 吗

分场景看：

老项目如果 main.ts 还在用platformBrowserDynamic，不用急着改。只要构建配置开启 AOT，最终产物并不会因为入口函数名带Dynamic就强制打包编译器。构建器会根据实际是否需要运行时编译来做 tree-shaking。当然，新项目没必要再刻意绕道，直接用bootstrapApplication更符合现在的主流实践。

5.4 一个容易被忽略的地方：测试工具链仍在依赖动态编译

Angular 单测环境里有一个很固定的配置：

import { getTestBed } from '@angular/core'; import { BrowserDynamicTestingModule, platformBrowserDynamicTesting, } from '@angular/platform-browser-dynamic/testing'; getTestBed().initTestEnvironment( BrowserDynamicTestingModule, platformBrowserDynamicTesting() );

这段代码在 angular.json 的test配置或src/test.ts里都能看到。单元测试跑的是组件源码，没有经过构建期 AOT 编译，TestBed 必须用 JIT 编译器现场把模板编译成视图。所以platform-browser-dynamic/testing这个包直到今天还在活跃使用。这也解释了为什么 Angular 没有彻底删除 JIT 路径：测试场景需要它。

6. 日常开发里的选型与排查经验

6.1 三步判断你的项目走的是哪条编译路线

第一步，看angular.json或angular.json里构建目标的配置，确认是否存在aot: false。新版本 Angular CLI 默认开启 AOT，老项目可能手动关掉过。

第二步，看 main.ts 入口。bootstrapApplication基本可以断定是 AOT 路线；platformBrowserDynamic()则还需结合构建配置判断。

第三步，看构建产物。生产构建完成后，搜索产物里是否有@angular/compiler相关 chunk。没有就说明运行时没有编译器，走的是完整 AOT。这个检查方法最直接，不被源码表象误导。

# 构建产物目录里搜 compiler 关键字 grep -r "@angular/compiler" dist

没有输出，基本可以放心。

6.2 三个容易踩的认知误区

误区一：看到platformBrowserDynamic就认为项目没有开 AOT。实际上很多老项目的入口一直是它，但构建配置早就开了 AOT，运行时并不需要 JIT。源码入口名只是历史遗留。

误区二：AOT 就必须写bootstrapModuleFactory。那是 View Engine 时代的写法，Ivy 之后已经没有.ngfactory.ts文件，CLI 也封装了这些细节。现在你不需要亲手处理模块工厂。

误区三：platform-browser和platform-browser-dynamic是二选一。二者是叠加关系，动态编译平台本身就建立在浏览器平台之上。JIT 运行时同时拥有两者，AOT 运行时只需要前者。搞清这个关系，调试启动流程时思路会清晰很多。

6.3 几条实操建议

新项目直接走 Standalone 模式，main.ts 用bootstrapApplication，默认 AOT，简洁少坑。老项目不必为了"看起来规范"强行改入口，重点确认生产构建的 AOT 选项处于开启状态，并定期检查产物里有没有多余的 compiler chunk。

做 SSR 时格外注意：服务端渲染入口不要引入 JIT 依赖。服务端应用应该消费 AOT 产物，通过@angular/platform-server渲染。如果服务端 bundle 里混入 JIT 编译器，不仅体积变大，还可能在 Node 环境触发意想不到的编译行为。

排查启动报错时，先区分是运行时问题还是编译期问题。凡是出现JIT compilation failed、'@angular/compiler' not loaded，优先级最高的是找出谁在运行时触发编译，而不是先怀疑版本冲突或依赖缺失。

6.4 我对这套设计的一点体会

拆开platform-browser和platform-browser-dynamic这件事，短期看只是多了一个包，长期看其实决定了 Angular 的运行策略能灵活演进。编译器提前到构建期，运行时保持轻量，平台层抽象让渲染逻辑不绑定某个具体宿主。这个取舍最初可能会让初学者困惑，但踩过一轮坑之后会发现，问题定位路径其实是清晰的。

我在实际项目里最后的建议是：源码层面的入口，跟着项目自身的历史走，不要为了统一而统一；但构建配置和产物分析，一定要定期确认 AOT 确实生效。前者影响代码风格，后者直接影响线上性能和首屏体验。把这两个包的分工真正放在心上，遇到启动阶段的各种疑难杂症，排查起来会顺手很多。