在以下情况下，应该将什么响应代码传递给客户端？
用户注册时传递了无效数据，例如错误的电子邮件格式用户名/电子邮件已存在
我选择了403。我也发现以下我觉得可以使用。
Wikipedia: 412 Precondition Failed : 服务器不满足请求者对请求提出的先决条件之一
如果我应该使用 403 以外的代码，请建议代码。
在这两种情况下，400 都是最佳选择。如果您想进一步澄清错误，您可以更改原因短语或包含解释错误的正文。
412 - 使用最后修改日期和 ETags 时，前提条件失败用于条件请求。
403 - 当服务器希望阻止对资源的访问时使用 Forbidden。
唯一可能的其他选择是 422 - Unprocessable entity。
我会推荐 422。它不是主要 HTTP 规范的一部分，但它是由公共标准 (WebDAV) 定义的，浏览器应该像对待任何其他 4xx 状态代码一样对待它。
从 RFC 4918：
422（Unprocessable Entity）状态码意味着服务器理解请求实体的内容类型（因此 415（Unsupported Media Type）状态码是不合适的），并且请求实体的语法是正确的（因此是 400（Bad Request） ) 状态码不合适）但无法处理包含的指令。例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会出现这种错误情况。
如果无法正确解析请求（包括请求实体/正文），则相应的响应为 400 Bad Request [1]。
RFC 4918 声明 422 Unprocessable Entity 适用于请求实体在语法上格式正确但语义错误的情况。因此，如果请求实体出现乱码（例如错误的电子邮件格式），请使用 400；但如果它只是没有意义（如 @example.com）使用 422。
如果问题是，如问题中所述，用户名/电子邮件已经存在，您可以使用 409 Conflict [2] 来描述冲突，并提供有关如何修复的提示它（在这种情况下，“选择不同的用户名/电子邮件”）。但是，在编写的规范中，403 Forbidden [3] 也可以在这种情况下使用，尽管有关于 HTTP 授权的参数。
412 Precondition Failed [4] 用于客户端提供的前置条件请求标头（例如 If-Match） 评估为 false。也就是说，客户要求某些东西并提供先决条件，完全清楚这些先决条件可能会失败。 412 绝不应该突然出现在客户端上，并且不应该与请求实体本身相关。
将 418 I'm a teapot 返回到显然是精心设计或恶意且“不可能发生”的请求很有趣，例如 CSRF 检查失败或缺少请求属性。
2.3.2 418 I'm a teapot 任何尝试用茶壶冲泡咖啡都会导致错误代码“418 I'm a teapot”。生成的实体主体可能又短又粗。
为了保持它相当严肃，我将有趣的错误代码的使用限制在不直接暴露给用户的 RESTful 端点上。
418 I'm a teapot :)
