深入理解 Angular ServerRequestUrlFactory 的功能与原理

在这段 Angular 代码内部，存在一个名为 serverRequestUrlFactory 的函数。它的核心作用是返回一个能够动态获取请求地址的工厂函数，用于在服务端渲染或预渲染场景中确定实际的请求 URL。需要关注注入内容、可选参数以及不同渲染模式下的逻辑。以下文字分段介绍每一行 TypeScript 代码所做的事情，并且通过循序渐进的方式分析这段代码想要实现的目的。文章会在结尾提供一段可运行示例，展现如何将其集成到 Angular SSR 架构当中。为便于阅读，中文字符与英文字符之间会有空格分隔，但中文字符与中文字符之间不添加空格。

第一个部分是函数签名: export function serverRequestUrlFactory(options?: ServerOptions): Function { 这里声明了一个名为 serverRequestUrlFactory 的导出函数，接受可选的 options 作为参数，这个 options 类型很可能是自定义的 ServerOptions，用来配置服务端相关信息。它的返回值是一个 Function 类型，意味着返回的是一个可调用的函数。

紧接着是工厂函数的返回: return (): string => { 这个箭头函数在被调用时返回一个 string 类型。它之所以用闭包形式返回函数，是因为在 Angular 中，工厂提供函数 (Factory Provider) 经常会以这种方式返回真正想使用的值。这样做可以让框架在依赖注入阶段或某些懒加载时机执行注入并拿到最终结果。

下面开始注入依赖: const platformConfig = inject(INITIAL_CONFIG); 这一行通过 Angular 提供的 inject 函数来获取 INITIAL_CONFIG 对应的注入值。INITIAL_CONFIG 通常用于在 Angular SSR 环境里传递一些在服务端渲染时特有的配置信息，比如 document、url 等参数。这里得到的 platformConfig 里最常见的属性是 url，它可能表示当前渲染时所使用的绝对或相对路径信息。

随后一行: const serverRequestOrigin = inject(SERVER_REQUEST_ORIGIN); 这里注入的 SERVER_REQUEST_ORIGIN 是在服务端场景下可用的一个值，通常是指请求的协议 + 域名 + 端口等信息，也就是我们平时可能称为 origin 的部分。例如 https://example.com 或者 http://localhost:4200。这样做能让代码根据实际请求来源来拼接完整地址。

紧接着: const serverRequestUrl = inject(SERVER_REQUEST_URL, { optional: true, skipSelf: true, }); serverRequestUrl 是一个可选且 skipSelf 的注入项目，这说明在当前注入上下文如果找不到 SERVER_REQUEST_URL，就会向上级注入器继续查找，但如果最终找不到也不会抛出异常，而是返回 undefined。这行注入代表在 SSR 模式下，可能已经有人把完整的请求地址 (包含路径、查询参数等) 注入进来。如果找不到，就说明当前可能处在一个并没有真实服务器请求的环境，比如预渲染场景 (prerendering mode)。

下面的代码是逻辑判断:

// SSR mode
if (serverRequestUrl) {
  // should override the automatically recognized origin
  if (options?.serverRequestOrigin) {
    return serverRequestUrl.replace(
      serverRequestOrigin,
      options.serverRequestOrigin
    );
  }
  return serverRequestUrl;
}

上面的注释显示这里处理的就是 SSR 模式，也就是有真实的服务器请求发生时的情境。当 serverRequestUrl 存在，就表明正在运行的场景里可以拿到实际请求完整 URL。如果在 options 参数里带了 serverRequestOrigin，就会用它来替换之前自动识别到的 serverRequestOrigin，也就是说通过 replace 方法，把旧的 origin 替换为新的 origin，从而形成自定义的地址。这样做可以灵活地配置场景，比如需要重写域名或者协议等。假如 options.serverRequestOrigin 没有传入，那么就直接使用原本的 serverRequestUrl 并返回。

后续处理另一个分支:

// prerendering mode (no express server)
return serverRequestOrigin + platformConfig.url;

注释说明这是预渲染 (prerendering) 模式，也就意味着并没有真正的服务器请求，因为有时我们会使用 Angular 自带的预渲染功能 (例如通过预先生成静态 HTML 文件)。在这种情况里，serverRequestUrl 并不存在。为了生成一个完整可用的 URL，代码将 serverRequestOrigin 和 platformConfig.url 拼接起来，从而得到一个完整的请求地址。这对于不依赖真实 HTTP 请求的预渲染场景相当有用，可以保证生成的页面链接正常，或者在需要自行模拟请求场景时有效。

综合来看，这段代码的整体功能是:

1. 返回一个能够在服务端或预渲染模式下都能正常计算最终请求 URL 的工厂函数。
2. 如果有 serverRequestUrl (说明正在真正的 SSR 服务器模式)，就返回该地址，或依据传入的 serverRequestOrigin 重写 origin。
3. 如果没有 serverRequestUrl (说明处于预渲染模式)，就通过 serverRequestOrigin + platformConfig.url 来拼出一个完整地址。

这种工厂函数常常会被用于配置 Angular SSR 下的各种请求逻辑。例如在服务端渲染时需要获取客户端请求地址，以进行服务端端口代理或其他高级处理。也可以在静态文件预渲染时，写入一个合适的 URL，避免后期 JS 执行出错。

以下是一个可运行的源代码示例，用来展示如何在 Angular SSR 工程中应用这段逻辑。假设需要在某个自定义模块里提供这个工厂函数，并让它在服务端渲染时被正确调用:

// 位于 server-request-url.factory.ts
import { inject } from '@angular/core';
import { INITIAL_CONFIG } from '@angular/platform-server';
import { SERVER_REQUEST_ORIGIN, SERVER_REQUEST_URL } from 'some-ssr-tokens';

export interface ServerOptions {
  serverRequestOrigin?: string;
}

export function serverRequestUrlFactory(options?: ServerOptions): Function {
  return (): string => {
    const platformConfig = inject(INITIAL_CONFIG);
    const serverRequestOrigin = inject(SERVER_REQUEST_ORIGIN);
    const serverRequestUrl = inject(SERVER_REQUEST_URL, {
      optional: true,
      skipSelf: true,
    });

    // SSR mode
    if (serverRequestUrl) {
      // should override the automatically recognized origin
      if (options?.serverRequestOrigin) {
        return serverRequestUrl.replace(
          serverRequestOrigin,
          options.serverRequestOrigin
        );
      }
      return serverRequestUrl;
    }

    // prerendering mode (no express server)
    return serverRequestOrigin + platformConfig.url;
  };
}

示例如何在 Angular SSR 里使用:

// 位于 app.server.module.ts
import { NgModule } from '@angular/core';
import { ServerModule } from '@angular/platform-server';
import { AppModule } from './app.module';
import { serverRequestUrlFactory, ServerOptions } from './server-request-url.factory';

@NgModule({
  imports: [
    AppModule,
    ServerModule
  ],
  providers: [
    {
      provide: 'APP_SERVER_REQUEST_URL',
      useFactory: () => serverRequestUrlFactory({
        serverRequestOrigin: 'https://my-custom-domain.com'
      })(),
    }
  ],
  bootstrap: [/* AppComponent 或者其他组件 */]
})
export class AppServerModule {}

在这个示例中，使用者通过 useFactory 调用了 serverRequestUrlFactory，同时传入了一个自定义 origin。如果在 SSR 环境中，这段代码就会在检测到 serverRequestUrl 存在的时候，将其内部的 origin 替换为用户自定义的 https://my-custom-domain.com。假如没有 serverRequestUrl，那么就会使用 serverRequestOrigin + platformConfig.url 的拼接结果。这段逻辑让 SSR 渲染时能够获得可自由配置的 URL 信息，方便做跨域代理或其他服务端自定义需求。这个 APP_SERVER_REQUEST_URL 可以在服务端注入给其他服务或者组件进行使用，获取到最终要在服务端渲染使用的完整请求地址。

在运用这段逻辑时，需要确保在 SSR 服务器中已经通过相应的方式把 SERVER_REQUEST_URL 和 SERVER_REQUEST_ORIGIN 提前注入到 Angular 应用当中。对于基于 Express 的应用，常常会借助 ngExpressEngine 配置注入逻辑，或者在服务器端渲染引擎初始化时自行将这些值传递给 Angular 的服务器模块。对 prerendering 而言，serverRequestUrl 往往不会出现，这正好触发代码中的另一分支逻辑。这样一来，无论是否通过真实服务器获取请求，都能够生成正确的 URL。

通过这些步骤，serverRequestUrlFactory 能够为使用者提供一条灵活可配置的请求地址生成通路。对 SSR 模式来说，如果请求真实发生，可以截获真实 URL 并进行替换；对 prerendering 模式来说，可以把 serverRequestOrigin 和预渲染中的配置 URL 拼接起来完成模拟地址。两种模式都可以无缝协作，简化了服务端渲染和预渲染的差异。

这个设计理念能更好地支持 Angular SSR 的可扩展性，让开发者在需要根据运行环境定制请求时有更多自由度。举例而言，如果需要在同一个应用里同时支持多域名映射，或者在本地调试时需要自动把请求路径替换为 localhost，都可以通过传入的 options 进行灵活实现。

以上介绍涵盖了每一行关键代码的作用，并且展示了示例用法，能够让阅读者了解在 Angular SSR 环境下，这个函数如何确定最终的请求 URL，并同时兼顾服务端场景与预渲染场景的差异。这样的方法在 Angular 生态中相当常见，常用来适配运行时上下文的不同要求，为后续的编程提供更好的灵活性与可维护性。