默认情况下，Remix 将为你生成 HTTP 响应。如果你想自定义此行为，可以运行 npx remix reveal 来生成优先的 app/entry.server.tsx（或 .jsx）。此模块的 default 导出是一个函数，允许你创建响应，包括 HTTP 状态、标头和 HTML，让你完全控制标记的生成和发送到客户端的方式。
¥By default, Remix will handle generating the HTTP Response for you. If you want to customize this behavior, you can run npx remix reveal to generate an app/entry.server.tsx (or .jsx) that will take precedence. The default export of this module is a function that lets you create the response, including HTTP status, headers, and HTML, giving you full control over the way the markup is generated and sent to the client.
此模块应使用 <RemixServer> 元素以及当前请求的 context 和 url 元素来渲染当前页面的标记。一旦 JavaScript 使用 浏览器入口模块 在浏览器中加载，此标记将（可选）重新水化。
¥This module should render the markup for the current page using a <RemixServer> element with the context and url for the current request. This markup will (optionally) be re-hydrated once JavaScript loads in the browser using the browser entry module.
handleDataRequest你可以导出一个可选的 handleDataRequest 函数，该函数允许你修改数据请求的响应。这些请求不会渲染 HTML，而是在客户端数据融合 (hydration) 完成后将加载器和操作数据返回给浏览器。
¥You can export an optional handleDataRequest function that will allow you to modify the response of a data request. These are the requests that do not render HTML but rather return the loader and action data to the browser once client-side hydration has occurred.
export function handleDataRequest(
response: Response,
{
request,
params,
context,
}: LoaderFunctionArgs | ActionFunctionArgs
) {
response.headers.set("X-Custom-Header", "value");
return response;
}
handleError默认情况下，Remix 会将遇到的服务器端错误记录到控制台。如果你希望更好地控制日志记录，或者还希望将这些错误报告给外部服务，那么你可以导出一个可选的 handleError 函数，该函数将赋予你控制权（并禁用内置的错误日志记录）。
¥By default, Remix will log encountered server-side errors to the console. If you'd like more control over the logging, or would like to also report these errors to an external service, then you can export an optional handleError function which will give you control (and will disable the built-in error logging).
export function handleError(
error: unknown,
{
request,
params,
context,
}: LoaderFunctionArgs | ActionFunctionArgs
) {
if (!request.signal.aborted) {
sendErrorToErrorReportingService(error);
console.error(formatErrorForJsonLogging(error));
}
}
请注意，通常应避免在请求中止时记录日志，因为 Remix 的取消和竞争条件处理可能会导致大量请求中止。
¥Note that you generally want to avoid logging when the request was aborted, since Remix's cancellation and race-condition handling can cause a lot of requests to be aborted.
¥Streaming Rendering Errors
当你通过 renderToPipeableStream 或 renderToReadableStream 流式传输 HTML 响应时，你自己的 handleError 实现将仅处理初始 shell 渲染期间遇到的错误。如果在后续的流式渲染过程中遇到渲染错误，则需要手动处理这些错误，因为 Remix 服务器此时已经发送了响应。
¥When you are streaming your HTML responses via renderToPipeableStream or renderToReadableStream, your own handleError implementation will only handle errors encountered during the initial shell render. If you encounter a rendering error during subsequent streamed rendering, you will need to handle these errors manually since the Remix server has already sent the Response by that point.
对于 renderToPipeableStream，你可以在 onError 回调函数中处理这些错误。你需要在 onShellReady 中切换一个布尔值，以便了解错误是 Shell 渲染错误（可以忽略）还是异步渲染错误（必须处理）。
¥For renderToPipeableStream, you can handle these errors in the onError callback function. You will need to toggle a boolean in onShellReady so you know if the error was a shell rendering error (and can be ignored) or an async rendering error (and must be handled).
例如，请参阅 Node 的默认 entry.server.tsx。
¥For an example, please refer to the default entry.server.tsx for Node.
对于 renderToReadableStream，你可以在 onError 回调函数中处理这些错误。
¥For renderToReadableStream, you can handle these errors in the onError callback function
例如，请参阅 Cloudflare 的默认 entry.server.tsx
¥For an example, please refer to the default entry.server.tsx for Cloudflare
¥Thrown Responses
请注意，这不会处理从 loader/action 函数抛出的 Response 实例。此处理程序的目的是查找代码中导致意外抛出错误的错误。如果你检测到某种情况并在 loader/action 中抛出 401/404 等 Response 错误，那么这是你的代码处理的预期流程。如果你还希望记录或将这些内容发送到外部服务，则应在抛出响应时完成。
¥Note that this does not handle thrown Response instances from your loader/action functions. The intention of this handler is to find bugs in your code which result in unexpected thrown errors. If you are detecting a scenario and throwing a 401/404/etc. Response in your loader/action then it's an expected flow handled by your code. If you also wish to log or send those to an external service, that should be done at the time you throw the response.
