单元测试构造500状态码HttpResponseMessage时Content应传什么

开发ASP.NET Core 6 Web API时，针对依赖HttpClient完成请求收发的服务层做单元测试，采用Mock HttpMessageHandler、手动构造HttpResponseMessage的实现方式。200 OK状态的响应模拟逻辑已经明确，仅需将业务数据对应的JSON赋值给Content属性即可，但不清楚模拟500服务端错误响应时，Content字段应该填充什么内容。
当前已完成的200场景模拟代码如下：

var handlerMock = new Mock<HttpMessageHandler>();
var response = new HttpResponseMessage
{
    StatusCode = HttpStatusCode.OK,
    Content = new StringContent(@"[{ ""id"": 1, ""title"": ""Cool post!""}, { ""id"": 100, ""title"": ""Some title""}]"),
};

500错误响应的Content没有统一强制要求，核心原则是完全匹配你要测试的业务逻辑对异常响应的处理分支，以及被调用外部服务的真实返回格式，常见模拟场景分为三类：

• 模拟标准结构化错误：大部分主流API服务返回500错误时会采用结构化JSON格式，ASP.NET Core默认返回的是ProblemDetails结构，对应模拟代码如下：

var serverErrorResponse = new HttpResponseMessage
{
    StatusCode = HttpStatusCode.InternalServerError,
    Content = new StringContent(@"{
        ""title"": ""系统内部错误"",
        ""status"": 500,
        ""detail"": ""数据库连接超时，请稍后重试""
    }", Encoding.UTF8, "application/json")
};

• 模拟第三方服务自定义错误格式：如果你调用的外部服务有专属的错误返回规范（比如部分业务系统返回{ "errCode":50001, "errMsg":"服务暂不可用" }格式），直接按照对方线上真实返回的错误结构构造Content即可，用来验证你的代码能不能正确解析错误信息、触发对应的异常处理逻辑。
• 模拟非结构化异常场景：需要覆盖服务返回纯文本错误、Nginx/IIS默认HTML错误页、甚至空Content的极端场景，验证你的代码遇到非预期格式的错误响应时，会不会出现未处理异常、有没有正确做容错降级。

提示：不要随意编造错误响应格式，所有模拟的Content必须和生产环境下外部服务的真实500响应保持一致，否则单元测试覆盖的场景和实际运行场景会不匹配，失去测试意义。

内容的提问来源于stack exchange，提问作者MiBuena