Angular CLI构建时多路由预渲染导致服务器重复启动问题解析

问题背景

在使用Angular CLI进行项目构建时，当应用配置了多个使用RenderMode.Prerender模式的路由时，会出现服务器被多次启动的问题。这会导致端口冲突，抛出EADDRINUSE错误，即端口已被占用的异常。

问题现象

开发者在app.routes.server.ts中配置了多个预渲染路由，例如：

{
  path: 'shop/:product',
  renderMode: RenderMode.Prerender,
  async getPrerenderParams() {
    return [
      'ccd8-123f',
      'f3ad-e1u4',
      'cvae-5ase',
    ].map(product => ({ product }));
  },
  fallback: PrerenderFallback.Server,
},
{
  path: '**',
  renderMode: RenderMode.Prerender,
}

当执行ng build命令时，服务器会被启动多次，每次对应一个预渲染路由。如果移除了server.ts中的isMainModule检查（这在某些部署场景如Azure iisnode上是必要的），就会触发端口冲突错误。

技术原理

这个问题源于Angular CLI的构建机制：

1. 预渲染工作流程：当配置了预渲染路由时，Angular CLI会启动一个服务器实例来生成静态页面
2. 多路由处理：每个预渲染路由都会触发独立的构建过程，导致服务器被多次实例化
3. 端口冲突：默认情况下，这些实例都尝试监听同一个端口（如4000），从而产生冲突

解决方案

官方推荐的解决方案是修改server.ts中的检查逻辑，使其既能适应构建时的多实例场景，又能满足生产环境部署需求：

const port = process.env['PORT'] || 4000;

if (isMainModule(import.meta.url) || import.meta.url.includes('iisnode')) {
  app.listen(port, () => {
    console.log(`Node Express server listening on http://localhost:${port}`);
  });
}

export const reqHandler = createNodeRequestHandler(app);

这个修改实现了：

1. 保留原始的主模块检查
2. 添加对iisnode环境的特殊处理
3. 确保在构建时不会启动多余的服务实例

深入理解

预渲染机制

Angular的预渲染功能实际上是在构建时模拟浏览器访问，生成静态HTML文件。这个过程需要：

1. 启动一个临时的Node.js服务器
2. 访问配置的各个路由
3. 将渲染结果保存为静态文件

多进程构建

现代构建工具通常会利用多进程来加速构建过程。Angular CLI在处理预渲染路由时，可能会为每个路由或路由组启动独立的工作进程，这解释了为什么服务器会被多次初始化。

环境适配

在Azure iisnode等特殊部署环境下，传统的模块检查机制可能不适用，因为：

1. iisnode会以非主模块的方式加载应用
2. 需要确保服务器实例能被正确初始化
3. 同时避免开发构建时的冲突

最佳实践

1. 环境区分：明确区分构建时和运行时的环境变量
2. 端口管理：考虑使用动态端口分配或端口检测机制
3. 日志记录：添加详细的日志帮助诊断启动问题
4. 配置检查：验证路由配置，避免不必要的预渲染

总结

这个问题展示了Angular应用在不同阶段（开发构建与生产运行）的差异性需求。通过理解Angular CLI的构建机制和预渲染工作原理，开发者可以更好地处理这类环境适配问题，确保应用在各种场景下都能正确运行。