Angular 核心包解析：platform-browser 与 dynamic 的底层分工

import { bootstrapApplication } from '@angular/platform-browser';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent).catch(err => console.error(err));

这种写法的核心特征是：启动链路完全在 @angular/platform-browser 内闭环，你并不需要 @angular/platform-browser-dynamic 提供的 JIT 编译平台。

@angular/platform-browser-dynamic 的作用

它的关键词是 JIT

从包描述层面，它被定义为 library for using Angular in a web browser with JIT compilation。 从 API 形态层面，它提供的典型入口是 platformBrowserDynamic。更值得注意的是，在 Angular 新版 API 文档里，platformBrowserDynamic 这个入口本身被标记为 deprecated，并给出迁移提示：推荐改用 @angular/platform-browser 里的 platformBrowser；如果你不是 CLI 应用且依赖 JIT，还需要显式引入 @angular/compiler。

这段提示信息非常'硬核'，它等于告诉你两件事：

• Angular 团队在鼓励更多场景走 非 JIT 的启动方式
• 一旦你确实要走 JIT，编译器这件事必须被严肃对待，甚至需要显式引入 @angular/compiler 来把链路补齐

经典的模块启动例子

你在较传统的 NgModule 项目里，大概率见过这种写法：

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { AppModule } from './app/app.module';

platformBrowserDynamic().bootstrapModule(AppModule).catch(err => console.error(err));

它的语义很直观：用 platformBrowserDynamic 创建一个带动态编译能力的浏览器平台，再去 bootstrap 一个模块。

两者的核心区别：不是'能不能在浏览器跑'，而是'编译在什么时候发生'

把差异说清楚，关键是把 编译时机 放在中心位置。

JIT 与 AOT 的差别如何影响这两个包

Angular 早期官方文档对 AOT 与 JIT 的对比给出了非常具体的结论：

• JIT：在浏览器运行时编译，带来运行时性能成本，首屏渲染更慢，包体更大，因为编译器和很多并非必要的库代码会被带到客户端
• AOT：构建时编译，浏览器下载的是预编译版本，渲染更快；无需下载 Angular 编译器，payload 更小；模板错误更早暴露；安全性更好

把这段结论映射回依赖关系：

• @angular/platform-browser 更贴近 AOT 时代的浏览器运行时底盘：你只需要运行时，把编译尽量留在构建阶段
• @angular/platform-browser-dynamic 则是 JIT 路径的关键组成：它的存在价值就是把'运行时编译'这条路铺平

所以它们的区别不是'谁更高级'，而是'你选择把成本放在构建期还是用户浏览器里'。

为什么很多项目会同时依赖两者

现实项目里最常见的原因并不神秘，反而非常工程化：

原因一：历史脚手架与默认入口

大量项目从 NgModule 时代一路升级过来，main.ts 仍然使用 platformBrowserDynamic().bootstrapModule(...)。这种情况下保留 @angular/platform-browser-dynamic 很自然。

原因二：测试体系的惯性

即使你的生产代码已经改成 standalone + bootstrapApplication，单元测试里仍可能通过 TestBed 走到 JIT 平台能力，或者依赖 platform-browser-dynamic/testing 相关模块。这会让依赖在 package.json 里长期存在。

原因三：确实存在运行时编译需求

少数场景会动态加载带装饰器的类、或以某种方式依赖运行时编译链路。Angular 的态度也很明确：如果依赖 JIT，在某些情况下你需要显式引入 @angular/compiler。

把差异落到可操作的判断

你可以用下面这组判断把问题一次性定性：

• 你在 main.ts 看到 bootstrapApplication：倾向只需要 @angular/platform-browser，@angular/platform-browser-dynamic 多半来自历史代码或测试链路。
• 你在 main.ts 看到 platformBrowserDynamic().bootstrapModule(...)：@angular/platform-browser-dynamic 直接参与启动，它通常就是为了 JIT 或兼容传统启动方式。
• 你看到项目显式提示 @angular/compiler 未加载、或与 JIT 相关报错：说明运行时编译链路被触发，platform-browser-dynamic 与编译器依赖的关系就不是'可有可无'。

从 RxJS 角度补一刀：启动阶段的成本会直接影响流的时序体验

这里给一个更贴近工程体验的视角：JIT 把编译工作放进浏览器主线程，这会推迟首屏渲染，也会推迟你很多基于事件的 Observable 真正开始产生价值的时间窗口。AOT 则把这段成本尽量提前到构建期。

一个很实用的小技巧是：把关键流的订阅挂到 bootstrap 完成之后，避免在启动抖动期就开始堆积事件或触发昂贵逻辑：

import { bootstrapApplication } from '@angular/platform-browser';
import { fromEvent, from } from 'rxjs';
import { switchMap } from 'rxjs/operators';
import { AppComponent } from './app/app.component';

from(bootstrapApplication(AppComponent)).pipe(
  switchMap(() => fromEvent(window, 'scroll'))
).subscribe(() => {
  // 真正开始处理滚动事件
});

这段代码不关心你是 NgModule 还是 standalone，它表达的是：应用完成平台初始化与根组件挂载后，再启动事件流。在 JIT 场景里，这种分离的收益会更明显，因为启动阶段更'重'。

结论

• @angular/platform-browser 是 Angular 在浏览器环境的基础运行时平台，提供 BrowserModule、安全净化、平台创建与现代启动 API 等关键能力，几乎所有浏览器端 Angular 应用都会需要它。
• @angular/platform-browser-dynamic 的核心价值是支持 JIT 编译路径，把运行时编译能力带进浏览器端，因此常见于传统 platformBrowserDynamic().bootstrapModule(...) 启动方式与部分测试链路；新版 API 里 platformBrowserDynamic 入口被标记为 deprecated，并提示优先使用 platformBrowser，若依赖 JIT 还要显式引入 @angular/compiler。