` 型的可观察对象。
Many interceptors are only concerned with the outgoing request and return the event stream from `next.handle()` without modifying it.
Some interceptors, however, need to examine and modify the response from `next.handle()`; these operations can see all of these events in the stream.
很多拦截器只关心发出的请求，而对 `next.handle()` 返回的事件流不会做任何修改。
但是，有些拦截器需要检查并修改 `next.handle()` 的响应。上述做法就可以在流中看到所有这些事件。
{@a immutability}
Although interceptors are capable of modifying requests and responses,
the `HttpRequest` and `HttpResponse` instance properties are `readonly`,
rendering them largely immutable.
虽然拦截器有能力改变请求和响应，但 `HttpRequest` 和 `HttpResponse` 实例的属性却是只读（`readonly`）的，
因此让它们基本上是不可变的。
They are immutable for a good reason: an app might retry a request several times before it succeeds, which means that the interceptor chain can re-process the same request multiple times.
If an interceptor could modify the original request object, the re-tried operation would start from the modified request rather than the original. Immutability ensures that interceptors see the same request for each try.
有充足的理由把它们做成不可变对象：应用可能会重试发送很多次请求之后才能成功，这就意味着这个拦截器链表可能会多次重复处理同一个请求。
如果拦截器可以修改原始的请求对象，那么重试阶段的操作就会从修改过的请求开始，而不是原始请求。
而这种不可变性，可以确保这些拦截器在每次重试时看到的都是同样的原始请求。
Your interceptor should return every event without modification unless it has a compelling reason to do otherwise.
你的拦截器应该在没有任何修改的情况下返回每一个事件，除非它有令人信服的理由去做。
TypeScript prevents you from setting `HttpRequest` read-only properties.
TypeScript 会阻止你设置 `HttpRequest` 的只读属性。
```javascript
// Typescript disallows the following assignment because req.url is readonly
req.url = req.url.replace('http://', 'https://');
```
If you must alter a request, clone it first and modify the clone before passing it to `next.handle()`.
You can clone and modify the request in a single step, as shown in the following example.
如果你必须修改一个请求，先把它克隆一份，修改这个克隆体后再把它传给 `next.handle()`。你可以在一步中克隆并修改此请求，例子如下。
The `clone()` method's hash argument allows you to mutate specific properties of the request while copying the others.
这个 `clone()` 方法的哈希型参数允许你在复制出克隆体的同时改变该请求的某些特定属性。
#### Modifying a request body
#### 修改请求体
The `readonly` assignment guard can't prevent deep updates and, in particular,
it can't prevent you from modifying a property of a request body object.
`readonly` 这种赋值保护，无法防范深修改（修改子对象的属性），也不能防范你修改请求体对象中的属性。
```javascript
req.body.name = req.body.name.trim(); // bad idea!
```
If you must modify the request body, follow these steps.
如果必须修改请求体，请执行以下步骤。
1. Copy the body and make your change in the copy.
复制请求体并在副本中进行修改。
2. Clone the request object, using its `clone()` method.
使用 `clone()` 方法克隆这个请求对象。
3. Replace the clone's body with the modified copy.
用修改过的副本替换被克隆的请求体。
#### Clearing the request body in a clone
#### 克隆时清除请求体
Sometimes you need to clear the request body rather than replace it.
To do this, set the cloned request body to `null`.
有时，你需要清除请求体而不是替换它。为此，请将克隆后的请求体设置为 `null`。
**Tip**: If you set the cloned request body to `undefined`, Angular assumes you intend to leave the body as is.
**提示**：如果你把克隆后的请求体设为 `undefined`，那么 Angular 会认为你想让请求体保持原样。
```javascript
newReq = req.clone({ ... }); // body not mentioned => preserve original body
newReq = req.clone({ body: undefined }); // preserve original body
newReq = req.clone({ body: null }); // clear the body
```
### Setting default headers
### 设置默认请求头
Apps often use an interceptor to set default headers on outgoing requests.
应用通常会使用拦截器来设置外发请求的默认请求头。
The sample app has an `AuthService` that produces an authorization token.
Here is its `AuthInterceptor` that injects that service to get the token and
adds an authorization header with that token to every outgoing request:
该范例应用具有一个 `AuthService`，它会生成一个认证令牌。
在这里，`AuthInterceptor` 会注入该服务以获取令牌，并对每一个外发的请求添加一个带有该令牌的认证头：
The practice of cloning a request to set new headers is so common that
there's a `setHeaders` shortcut for it:
这种在克隆请求的同时设置新请求头的操作太常见了，因此它还有一个快捷方式 `setHeaders`：
An interceptor that alters headers can be used for a number of different operations, including:
这种可以修改头的拦截器可以用于很多不同的操作，比如：
* Authentication/authorization
认证 / 授权
* Caching behavior; for example, `If-Modified-Since`
控制缓存行为。比如 `If-Modified-Since`
* XSRF protection
XSRF 防护
### Using interceptors for logging
### 用拦截器记日志
Because interceptors can process the request and response *together*, they can perform tasks such as timing and logging an entire HTTP operation.
因为拦截器可以*同时*处理请求和响应，所以它们也可以对整个 HTTP 操作执行计时和记录日志等任务。
Consider the following `LoggingInterceptor`, which captures the time of the request,
the time of the response, and logs the outcome with the elapsed time
with the injected `MessageService`.
考虑下面这个 `LoggingInterceptor`，它捕获请求的发起时间、响应的接收时间，并使用注入的 `MessageService` 来发送总共花费的时间。
The RxJS `tap` operator captures whether the request succeeded or failed.
The RxJS `finalize` operator is called when the response observable either errors or completes (which it must),
and reports the outcome to the `MessageService`.
RxJS 的 `tap` 操作符会捕获请求成功了还是失败了。
RxJS 的 `finalize` 操作符无论在响应成功还是失败时都会调用（这是必须的），然后把结果汇报给 `MessageService`。
Neither `tap` nor `finalize` touch the values of the observable stream returned to the caller.
在这个可观察对象的流中，无论是 `tap` 还是 `finalize` 接触过的值，都会照常发送给调用者。
{@a caching}
### Using interceptors for caching
### 用拦截器实现缓存
Interceptors can handle requests by themselves, without forwarding to `next.handle()`.
拦截器还可以自行处理这些请求，而不用转发给 `next.handle()`。
For example, you might decide to cache certain requests and responses to improve performance.
You can delegate caching to an interceptor without disturbing your existing data services.
比如，你可能会想缓存某些请求和响应，以便提升性能。
你可以把这种缓存操作委托给某个拦截器，而不破坏你现有的各个数据服务。
The `CachingInterceptor` in the following example demonstrates this approach.
下例中的 `CachingInterceptor` 演示了这种方法。
* The `isCacheable()` function determines if the request is cacheable.
In this sample, only GET requests to the npm package search api are cacheable.
`isCacheable()` 函数用于决定该请求是否允许缓存。
在这个例子中，只有发到 npm 包搜索 API 的 GET 请求才是可以缓存的。
* If the request is not cacheable, the interceptor simply forwards the request
to the next handler in the chain.
如果该请求是不可缓存的，该拦截器只会把该请求转发给链表中的下一个处理器。
* If a cacheable request is found in the cache, the interceptor returns an `of()` *observable* with
the cached response, by-passing the `next` handler (and all other interceptors downstream).
如果可缓存的请求在缓存中找到了，该拦截器就会通过 `of()` 函数返回一个已缓存的响应体的*可观察对象*，然后绕过 `next` 处理器（以及所有其它下游拦截器）。
* If a cacheable request is not in cache, the code calls `sendRequest()`.
This function creates a [request clone](#immutability) without headers, because the npm API forbids them.
The function then forwards the clone of the request to `next.handle()` which ultimately calls the server and returns the server's response.
如果可缓存的请求不在缓存中，代码会调用 `sendRequest()`。这个函数会创建一个没有请求头的[请求克隆体](#immutability)，这是因为 npm API 禁止它们。然后，该函数把请求的克隆体转发给 `next.handle()`，它会最终调用服务器并返回来自服务器的响应对象。
{@a send-request}
{@a send-request}
Note how `sendRequest()` intercepts the response on its way back to the application.
This method pipes the response through the `tap()` operator, whose callback adds the response to the cache.
注意 `sendRequest()` 是如何在返回应用程序的过程中拦截响应的。该方法通过 `tap()` 操作符来管理响应对象，该操作符的回调函数会把该响应对象添加到缓存中。
The original response continues untouched back up through the chain of interceptors
to the application caller.
然后，原始的响应会通过这些拦截器链，原封不动的回到服务器的调用者那里。
Data services, such as `PackageSearchService`, are unaware that
some of their `HttpClient` requests actually return cached responses.
数据服务，比如 `PackageSearchService`，并不知道它们收到的某些 `HttpClient` 请求实际上是从缓存的请求中返回来的。
{@a cache-refresh}
### Using interceptors to request multiple values
### 用拦截器来请求多个值
The `HttpClient.get()` method normally returns an observable that emits a single value, either the data or an error.
An interceptor can change this to an observable that emits [multiple values](guide/observables).
`HttpClient.get()` 方法通常会返回一个可观察对象，它会发出一个值（数据或错误）。拦截器可以把它改成一个可以发出[多个值](guide/observables)的可观察对象。
The following revised version of the `CachingInterceptor` optionally returns an observable that
immediately emits the cached response, sends the request on to the npm web API,
and emits again later with the updated search results.
修改后的 `CachingInterceptor` 版本可以返回一个立即发出所缓存响应的可观察对象，然后把请求发送到 NPM 的 Web API，然后把修改过的搜索结果重新发出一次。
The *cache-then-refresh* option is triggered by the presence of a custom `x-refresh` header.
*cache-then-refresh* 选项是由一个自定义的 `x-refresh` 请求头触发的。
A checkbox on the `PackageSearchComponent` toggles a `withRefresh` flag,
which is one of the arguments to `PackageSearchService.search()`.
That `search()` method creates the custom `x-refresh` header
and adds it to the request before calling `HttpClient.get()`.
`PackageSearchComponent` 中的一个检查框会切换 `withRefresh` 标识，
它是 `PackageSearchService.search()` 的参数之一。
`search()` 方法创建了自定义的 `x-refresh` 头，并在调用 `HttpClient.get()` 前把它添加到请求里。
The revised `CachingInterceptor` sets up a server request
whether there's a cached value or not,
using the same `sendRequest()` method described [above](#send-request).
The `results$` observable makes the request when subscribed.
修改后的 `CachingInterceptor` 会发起一个服务器请求，而不管有没有缓存的值。
就像 [前面](#send-request) 的 `sendRequest()` 方法一样进行订阅。
在订阅 `results$` 可观察对象时，就会发起这个请求。
* If there's no cached value, the interceptor returns `results$`.
如果没有缓存值，拦截器直接返回 `results$`。
* If there is a cached value, the code _pipes_ the cached response onto
`results$`, producing a recomposed observable that emits twice,
the cached response first (and immediately), followed later
by the response from the server.
Subscribers see a sequence of two responses.
如果有缓存的值，这些代码就会把缓存的响应加入到 `result$` 的*管道*中，使用重组后的可观察对象进行处理，并发出两次。
先立即发出一次缓存的响应体，然后发出来自服务器的响应。
订阅者将会看到一个包含这两个响应的序列。
{@a report-progress}
## Tracking and showing request progress
## 跟踪和显示请求进度
Sometimes applications transfer large amounts of data and those transfers can take a long time.
File uploads are a typical example.
You can give the users a better experience by providing feedback on the progress of such transfers.
应用程序有时会传输大量数据，而这些传输可能要花很长时间。文件上传就是典型的例子。你可以通过提供有关此类传输的进度反馈，为用户提供更好的体验。
To make a request with progress events enabled, you can create an instance of `HttpRequest`
with the `reportProgress` option set true to enable tracking of progress events.
要想发出一个带有进度事件的请求，你可以创建一个 `HttpRequest` 实例，并把 `reportProgress` 选项设置为 true 来启用对进度事件的跟踪。
**Tip**: Every progress event triggers change detection, so only turn them on if you need to report progress in the UI.
**提示**：每个进度事件都会触发变更检测，所以只有当需要在 UI 上报告进度时，你才应该开启它们。
When using [`HttpClient.request()`](api/common/http/HttpClient#request) with an HTTP method, configure the method with
[`observe: 'events'`](api/common/http/HttpClient#request) to see all events, including the progress of transfers.
当 [`HttpClient.request()`](api/common/http/HttpClient#request) 和 HTTP 方法一起使用时，可以用 [`observe: 'events'`](api/common/http/HttpClient#request) 来查看所有事件，包括传输的进度。
Next, pass this request object to the `HttpClient.request()` method, which
returns an `Observable` of `HttpEvents` (the same events processed by [interceptors](#interceptor-events)).
接下来，把这个请求对象传递给 `HttpClient.request()` 方法，该方法返回一个 `HttpEvents` 的 `Observable`（与 [拦截器](#interceptor-events) 部分处理过的事件相同）。
The `getEventMessage` method interprets each type of `HttpEvent` in the event stream.
`getEventMessage` 方法解释了事件流中每种类型的 `HttpEvent`。
The sample app for this guide doesn't have a server that accepts uploaded files.
The `UploadInterceptor` in `app/http-interceptors/upload-interceptor.ts`
intercepts and short-circuits upload requests
by returning an observable of simulated events.
本指南中的示例应用中没有用来接受上传文件的服务器。`app/http-interceptors/upload-interceptor.ts` 的 `UploadInterceptor` 通过返回一个模拟这些事件的可观察对象来拦截和短路上传请求。
## Optimizing server interaction with debouncing
## 通过防抖来优化与服务器的交互
If you need to make an HTTP request in response to user input, it's not efficient to send a request for every keystroke.
It's better to wait until the user stops typing and then send a request.
This technique is known as debouncing.
如果你需要发一个 HTTP 请求来响应用户的输入，那么每次击键就发送一个请求的效率显然不高。最好等用户停止输入后再发送请求。这种技术叫做防抖。
Consider the following template, which lets a user enter a search term to find an npm package by name.
When the user enters a name in a search-box, the `PackageSearchComponent` sends
a search request for a package with that name to the npm web API.
考虑下面这个模板，它让用户输入一个搜索词来按名字查找 npm 包。
当用户在搜索框中输入名字时，`PackageSearchComponent` 就会把这个根据名字搜索包的请求发给 npm web API。
Here, the `keyup` event binding sends every keystroke to the component's `search()` method.
The following snippet implements debouncing for this input using RxJS operators.
这里，`keyup` 事件绑定会把每次击键都发送给组件的 `search()` 方法。下面的代码片段使用 RxJS 的操作符为这个输入实现了防抖。
The `searchText$` is the sequence of search-box values coming from the user.
It's defined as an RxJS `Subject`, which means it is a multicasting `Observable`
that can also emit values for itself by calling `next(value)`,
as happens in the `search()` method.
`searchText$` 是来自用户的搜索框值的序列。它被定义为 RxJS `Subject` 类型，这意味着它是一个多播 `Observable`，它还可以通过调用 `next(value)` 来自行发出值，就像在 `search()` 方法中一样。
Rather than forward every `searchText` value directly to the injected `PackageSearchService`,
the code in `ngOnInit()` pipes search values through three operators, so that a search value reaches the service only if it's a new value and the user has stopped typing.
除了把每个 `searchText` 的值都直接转发给 `PackageSearchService` 之外，`ngOnInit()` 中的代码还通过下列三个操作符对这些搜索值进行*管道*处理，以便只有当它是一个新值并且用户已经停止输入时，要搜索的值才会抵达该服务。
* `debounceTime(500)` - Wait for the user to stop typing (1/2 second in this case).
`debounceTime(500)` - 等待用户停止输入（本例中为 1/2 秒）。
* `distinctUntilChanged()` - Wait until the search text changes.
`distinctUntilChanged()` - 等待搜索文本发生变化。
* `switchMap()` - Send the search request to the service.
`switchMap()` - 将搜索请求发送到服务。
The code sets `packages$` to this re-composed `Observable` of search results.
The template subscribes to `packages$` with the [AsyncPipe](api/common/AsyncPipe)
and displays search results as they arrive.
这些代码把 `packages$` 设置成了使用搜索结果组合出的 `Observable` 对象。
模板中使用 [AsyncPipe](api/common/AsyncPipe) 订阅了 `packages$`，一旦搜索结果的值发回来了，就显示这些搜索结果。
See [Using interceptors to request multiple values](#cache-refresh) for more about the `withRefresh` option.
有关 `withRefresh` 选项的更多信息，请参阅[使用拦截器来请求多个值](#cache-refresh)。
### Using the *switchMap()* operator
### 使用 `switchMap()` 操作符
The `switchMap()` operator takes a function argument that returns an `Observable`.
In the example, `PackageSearchService.search` returns an `Observable`, as other data service methods do.
If a previous search request is still in-flight (as when the network connection is poor),
the operator cancels that request and sends a new one.
`switchMap()` 操作符接受一个返回 `Observable` 的函数型参数。在这个例子中，`PackageSearchService.search` 像其它数据服务方法那样返回一个 `Observable`。如果先前的搜索请求仍在*进行中* （如网络连接不良），它将取消该请求并发送新的请求。
Note that `switchMap()` returns service responses in their original request order, even if the
server returns them out of order.
请注意，`switchMap()` 会按照原始的请求顺序返回这些服务的响应，而不用关心服务器实际上是以乱序返回的它们。
If you think you'll reuse this debouncing logic,
consider moving it to a utility function or into the `PackageSearchService` itself.
如果你觉得将来会复用这些防抖逻辑，
可以把它移到单独的工具函数中，或者移到 `PackageSearchService` 中。
## Security: XSRF protection
## 安全：XSRF 防护
[Cross-Site Request Forgery (XSRF or CSRF)](https://en.wikipedia.org/wiki/Cross-site_request_forgery) is an attack technique by which the attacker can trick an authenticated user into unknowingly executing actions on your website.
`HttpClient` supports a [common mechanism](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Cookie-to-Header_Token) used to prevent XSRF attacks.
When performing HTTP requests, an interceptor reads a token from a cookie, by default `XSRF-TOKEN`, and sets it as an HTTP header, `X-XSRF-TOKEN`.
Since only code that runs on your domain could read the cookie, the backend can be certain that the HTTP request came from your client application and not an attacker.
[跨站请求伪造 (XSRF 或 CSRF)](https://en.wikipedia.org/wiki/Cross-site_request_forgery)是一个攻击技术，它能让攻击者假冒一个已认证的用户在你的网站上执行未知的操作。`HttpClient` 支持一种[通用的机制](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Cookie-to-Header_Token)来防范 XSRF 攻击。当执行 HTTP 请求时，一个拦截器会从 cookie 中读取 XSRF 令牌（默认名字为 `XSRF-TOKEN`），并且把它设置为一个 HTTP 头 `X-XSRF-TOKEN`，由于只有运行在你自己的域名下的代码才能读取这个 cookie，因此后端可以确认这个 HTTP 请求真的来自你的客户端应用，而不是攻击者。
By default, an interceptor sends this header on all mutating requests (such as POST)
to relative URLs, but not on GET/HEAD requests or on requests with an absolute URL.
默认情况下，拦截器会在所有的修改型请求中（比如 POST 等）把这个请求头发送给使用相对 URL 的请求。但不会在 GET/HEAD 请求中发送，也不会发送给使用绝对 URL 的请求。
To take advantage of this, your server needs to set a token in a JavaScript readable session cookie called `XSRF-TOKEN` on either the page load or the first GET request.
On subsequent requests the server can verify that the cookie matches the `X-XSRF-TOKEN` HTTP header, and therefore be sure that only code running on your domain could have sent the request.
The token must be unique for each user and must be verifiable by the server; this prevents the client from making up its own tokens.
Set the token to a digest of your site's authentication cookie with a salt for added security.
要获得这种优点，你的服务器需要在页面加载或首个 GET 请求中把一个名叫 `XSRF-TOKEN` 的令牌写入可被 JavaScript 读到的会话 cookie 中。
而在后续的请求中，服务器可以验证这个 cookie 是否与 HTTP 头 `X-XSRF-TOKEN` 的值一致，以确保只有运行在你自己域名下的代码才能发起这个请求。这个令牌必须对每个用户都是唯一的，并且必须能被服务器验证，因此不能由客户端自己生成令牌。把这个令牌设置为你的站点认证信息并且加了盐（salt）的摘要，以提升安全性。
In order to prevent collisions in environments where multiple Angular apps share the same domain or subdomain, give each application a unique cookie name.
为了防止多个 Angular 应用共享同一个域名或子域时出现冲突，要给每个应用分配一个唯一的 cookie 名称。
*`HttpClient` supports only the client half of the XSRF protection scheme.*
Your backend service must be configured to set the cookie for your page, and to verify that
the header is present on all eligible requests.
Failing to do so renders Angular's default protection ineffective.
*`HttpClient` 支持的只是 XSRF 防护方案的客户端这一半。* 你的后端服务必须配置为给页面设置 cookie，并且要验证请求头，以确保全都是合法的请求。如果不这么做，就会导致 Angular 的默认防护措施失效。
### Configuring custom cookie/header names
### 配置自定义 cookie/header 名称
If your backend service uses different names for the XSRF token cookie or header,
use `HttpClientXsrfModule.withOptions()` to override the defaults.
如果你的后端服务中对 XSRF 令牌的 cookie 或 头使用了不一样的名字，就要使用 `HttpClientXsrfModule.withConfig()` 来覆盖掉默认值。
{@a testing-requests}
## Testing HTTP requests
## 测试 HTTP 请求
As for any external dependency, you must mock the HTTP backend so your tests can simulate interaction with a remote server.
The `@angular/common/http/testing` library makes it straightforward to set up such mocking.
如同所有的外部依赖一样，你必须把 HTTP 后端也 Mock 掉，以便你的测试可以模拟这种与后端的互动。
`@angular/common/http/testing` 库能让这种 Mock 工作变得直截了当。
Angular's HTTP testing library is designed for a pattern of testing in which the app executes code and makes requests first.
The test then expects that certain requests have or have not been made,
performs assertions against those requests,
and finally provides responses by "flushing" each expected request.
Angular 的 HTTP 测试库是专为其中的测试模式而设计的。在这种模式下，会首先在应用中执行代码并发起请求。
然后，这个测试会期待发起或未发起过某个请求，并针对这些请求进行断言，
最终对每个所预期的请求进行刷新（flush）来对这些请求提供响应。
At the end, tests can verify that the app has made no unexpected requests.
最终，测试可能会验证这个应用不曾发起过非预期的请求。
You can run these sample tests
in a live coding environment.
你可以到在线编程环境中运行这些范例测试。
The tests described in this guide are in `src/testing/http-client.spec.ts`.
There are also tests of an application data service that call `HttpClient` in
`src/app/heroes/heroes.service.spec.ts`.
本章所讲的这些测试位于 `src/testing/http-client.spec.ts` 中。
在 `src/app/heroes/heroes.service.spec.ts` 中还有一些测试，用于测试那些调用了 `HttpClient` 的数据服务。
### Setup for testing
### 搭建测试环境
To begin testing calls to `HttpClient`,
import the `HttpClientTestingModule` and the mocking controller, `HttpTestingController`,
along with the other symbols your tests require.
要开始测试那些通过 `HttpClient` 发起的请求，就要导入 `HttpClientTestingModule` 模块，并把它加到你的 `TestBed` 设置里去，代码如下：
Then add the `HttpClientTestingModule` to the `TestBed` and continue with
the setup of the _service-under-test_.
然后把 `HTTPClientTestingModule` 添加到 `TestBed` 中，并继续设置*被测服务*。
Now requests made in the course of your tests hit the testing backend instead of the normal backend.
现在，在测试中发起的这些请求会发给这些测试用的后端（testing backend），而不是标准的后端。
This setup also calls `TestBed.inject()` to inject the `HttpClient` service and the mocking controller
so they can be referenced during the tests.
这种设置还会调用 `TestBed.inject()`，来获取注入的 `HttpClient` 服务和模拟对象的控制器 `HttpTestingController`，以便在测试期间引用它们。
### Expecting and answering requests
### 期待并回复请求
Now you can write a test that expects a GET Request to occur and provides a mock response.
现在，你就可以编写测试，等待 GET 请求并给出模拟响应。
The last step, verifying that no requests remain outstanding, is common enough for you to move it into an `afterEach()` step:
最后一步，验证没有发起过预期之外的请求，足够通用，因此你可以把它移到 `afterEach()` 中：
#### Custom request expectations
#### 自定义对请求的预期
If matching by URL isn't sufficient, it's possible to implement your own matching function.
For example, you could look for an outgoing request that has an authorization header:
如果仅根据 URL 匹配还不够，你还可以自行实现匹配函数。
比如，你可以验证外发的请求是否带有某个认证头：
As with the previous `expectOne()`,
the test fails if 0 or 2+ requests satisfy this predicate.
像前面的 `expectOne()` 测试一样，如果零或两个以上的请求满足了这个断言，它就会抛出异常。
#### Handling more than one request
#### 处理一个以上的请求
If you need to respond to duplicate requests in your test, use the `match()` API instead of `expectOne()`.
It takes the same arguments but returns an array of matching requests.
Once returned, these requests are removed from future matching and
you are responsible for flushing and verifying them.
如果你需要在测试中对重复的请求进行响应，可以使用 `match()` API 来代替 `expectOne()`，它的参数不变，但会返回一个与这些请求相匹配的数组。一旦返回，这些请求就会从将来要匹配的列表中移除，你要自己验证和刷新（flush）它。
### Testing for errors
### 测试对错误的预期
You should test the app's defenses against HTTP requests that fail.
你还要测试应用对于 HTTP 请求失败时的防护。
Call `request.flush()` with an error message, as seen in the following example.
调用 `request.flush()` 并传入一个错误信息，如下所示：
Alternatively, you can call `request.error()` with an `ErrorEvent`.
另外，你还可以使用 `ErrorEvent` 来调用 `request.error()`.