看懂 @angular/platform-browser 与 @angular/platform-browser-dynamic：浏览器运行时与编译策略的分工

你在 package.json 里看到 @angular/platform-browser 和 @angular/platform-browser-dynamic，本质上是在同一件事的两个阶段里看到了两套能力：让 Angular 在浏览器里跑起来，以及用哪种方式把 Angular 应用变成浏览器可执行的东西。把这两点拆开，你就能很稳定地判断它们各自的作用与差异。

观察线索与推理起点

当 package.json 同时出现这两个依赖时，意味着项目至少满足下面两条中的一条：

• 代码在浏览器端需要完整的浏览器运行时支持，这部分由 @angular/platform-browser 提供（几乎所有浏览器端 Angular 应用都会需要）。@angular/platform-browser 的包定位就是 library for using Angular in a web browser。(Yarn)
• 项目在某些场景会使用或保留 JIT 编译路径（在浏览器运行时编译），或测试体系依赖 JIT 平台能力，这就会引入 @angular/platform-browser-dynamic。它的包定位明确写了 with JIT compilation。(Yarn)

接下来把 platform 这个词讲清楚，区别自然就出来了。

Angular 里的 platform 到底是什么

在 Angular 语境里，platform 可以理解为：一组与运行环境绑定的底层服务提供者集合。同样的框架核心（DI、组件模型、变更检测等）要跑在不同环境里，需要不同的“底盘”：

• 浏览器环境：DOM 渲染、事件系统、安全净化、title 与 meta 管理、浏览器特有的调试能力、以及现代 SSR 体系下的 hydration 相关能力等
• 服务端环境：SSR 渲染与请求级别的隔离等
• 测试环境：TestBed、模拟渲染与编译策略等

所以 @angular/platform-browser 更像是浏览器底盘，@angular/platform-browser-dynamic 则是在这个底盘之上额外加了一套运行时编译发动机。

@angular/platform-browser 的作用

它提供浏览器端必需的基础设施

Angular 官方 API 对 BrowserModule 的描述非常直白：Exports required infrastructure for all Angular apps，并且在 CLI 创建的应用里默认包含。(Angular)

这句话背后对应的能力，落到开发者日常能感知到的点包括：

• DOM 渲染与事件体系的接入：让组件模板最终变成真实 DOM，并绑定事件
• 安全相关的净化与类型封装：例如 DomSanitizer 的存在就是为了降低 XSS 风险，避免把危险内容直接注入 DOM 上下文。(Angular)
• 应用启动与平台创建相关 API：bootstrapApplication、createApplication、platformBrowser 等都在这个包里。比如 bootstrapApplication 用于启动一个以 standalone component 为根的应用。(Angular)

再抓一个很“底层”的点：platformBrowser 本身在 API 里被定义为返回与浏览器服务提供者关联的 PlatformRef。(Angular)
这说明它解决的是“我在浏览器里要用哪些系统级 provider”这类问题，而不是“我要不要把编译器带到浏览器里”。

一个更贴近现代 Angular 的启动例子

在较新的 Angular 风格里，你可能在 main.ts 看到类似写法（standalone）：

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。(Yarn)
从 API 形态层面，它提供的典型入口是 platformBrowserDynamic。更值得注意的是，在 Angular 新版 API 文档里，platformBrowserDynamic 这个入口本身被标记为 deprecated，并给出迁移提示：推荐改用 @angular/platform-browser 里的 platformBrowser；如果你不是 CLI 应用且依赖 JIT，还需要显式引入 @angular/compiler。(Angular)

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

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

经典的模块启动例子

你在较传统的 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：在浏览器运行时编译，带来运行时性能成本，首屏渲染更慢，包体更大，因为编译器和很多并非必要的库代码会被带到客户端 (v2.angular.io)
• AOT：构建时编译，浏览器下载的是预编译版本，渲染更快；无需下载 Angular 编译器，payload 更小；模板错误更早暴露；安全性更好 (v2.angular.io)

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

• @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。(Angular)

把差异落到可操作的判断

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

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

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

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

一个很实用的小技巧是：把关键流的订阅挂到 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 场景里，这种分离的收益会更明显，因为启动阶段更“重”。(v2.angular.io)

结论

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

如果你愿意贴一段项目的 main.ts（或说明是 standalone 还是 NgModule），我可以把你这个项目里它们各自“为什么在”、以及“能不能安全移除其中一个”的判断路径直接写成一份可执行的改造清单。