这完全取决于如何解释各种http状态码，以及您希望您的http负载响应对用户友好程度如何。以下是一些建议：
创建的新用户：如果它是一个新用户并且在后端成功创建，那么返回http状态码201。这是一个技术状态代码。您还可以在响应正文中返回一个功能状态，其中提到“user created”https://developer.mozilla.org/en-us/docs/web/http/status/201
用户已存在：如果用户已存在，则应使用http状态代码200进行响应，响应有效负载正文中提到功能状态“用户已存在”
用户创建失败：如果后端服务不满足新的用户规则并抛出错误，则可以使用http状态码400，响应负载中的功能状态为“用户创建失败，请遵守用户名规则”https://developer.mozilla.org/en-us/docs/web/http/status/400
为了让api使用者了解您的api的所有信息，您可能需要提供一个api规范文档。您可以使用openapi规范（以前称为swagger）https://swagger.io/specification/

案例1:3xx描述“重定向错误”，所以这里不是这样，你需要决定如何定义这个问题，如果你认为问题出在试图发布现有用户的客户身上，你可以返回409；如果你专注于试图在数据库中保存现有用户的服务器端，你可以返回500，这完全取决于你(有些人会说，返回200与一个适当的信息，它也可以）
案例2：这种规则应该在前端进行管理，但是如果您仍然希望在服务器上执行，则可以返回403。此外，还有控制器方法的注解，可以帮助您验证这种规则。
在任何情况下：异常只针对服务器端，您可以根据异常返回一个描述，并带有http状态。

不知何故，我想让api使用者知道要处理哪种json结构，我猜http状态代码对此有帮助吗？
不完全是。
http状态码是通过网络域传输文档中的元数据。它传递响应的整体语义（例如，消息体是资源的表示，还是错误的表示？这个React是否可信？以此类推）。
特别是对于不安全的请求，缓存失效对“非错误状态码”非常敏感。303（非错误状态代码）和409（错误状态代码）之间的差异可能很大。
content-type头提供了一种机制来描述返回的消息的类型（模式）（例如：application/problem+json）。
我的想法是：定制消费者的信息属于消息体；我们将数据从消息体提升到http元数据，以便通用组件可以利用这些信息（例如，通过使缓存项无效）。
因此，我们通常从定义消息体的模式和语义开始，并确保我们有智能的方法来传达我们希望调用者知道的所有事情。换句话说，我们定义了传递给客户机的文档，以及如何从中提取信息。
http组件需要知道的信息将从定制文档复制到标准化的表单（状态码、头）。
当事情变得复杂时：事实上某些东西在你的域中是一个“错误”，这并不一定意味着在通过网络域传输文档时它也应该被认为是一个“错误”。
一个常见的情况是：我们使用api在流程中导航一些工作；这个过程有一条快乐的道路，也有一些我们通常试图避免的例外道路（账户透支、物品缺货等）。
http请求可以将工作从愉快路径移动到异常路径，并且在文档域的传输中仍然是“成功”的。
我知道的最简单的启发式方法是考虑相同目标uri以前缓存的响应副本。如果这些响应仍然是可重用的，那么您可能正在查看4xx状态代码。如果响应应该无效，那么您可能看到的是2xx或3xx状态码。