很明显，一些表单POST请求会导致4xx HTTP错误(例如错误的URL、缺少预期字段、无法发送auth cookie)，但现有的此类问题似乎表明，所有无效表单提交都应被视为4xx HTTP错误。真正地
错误键入密码或意外遗漏所需字段是非常常见的，在应用程序中会出现。从任何规范来看，似乎都不清楚这些应该构成"HTTP客户端错误"，或者POST只有在产生永久状态更改的情况下才能被视为2xx成功。
我想我的直觉是，如果服务器向客户端发送一个表单，而客户端立即用正确格式的POST请求来回复该表单以及所有预期字段，那么常见的业务逻辑冲突不应该是HTTP错误。
如果表单是通过类似JSON-RPC的方式提交的，那么情况就更不明确了。HTTP只是一种传输机制，如果成功调用函数并将响应返回给调用者，则应该不会出现HTTP错误。
更罕见的是，一些形式可能会做多种事情，其中一部分可能成功，而另一部分则失败。
理想情况下，IETF会通过RFC来解决这个问题，可能会添加一个HTTP错误代码来表示"由于表单无效失败，操作没有执行"，或者扩展422的定义来涵盖这个问题。
这里没有对错之分。我认为HTML表单在某种程度上与HTTP的设计背道而驰。
这里的浏览器是一个HTTP客户端。如果它提交了一个请求，但收到了一个HTTP错误，它将回显响应的主体，但对响应代码几乎没有什么作用。
从HTTP的角度来看，也许浏览器不应该对错误进行"刷新"。也许它应该只是向用户传达一个错误，并允许他们更改表单并重新尝试请求。
不过，从HTML的角度来看，最明智的做法是根本不发回错误，而是重定向回表单的URL，通常带有一组查询参数。
在JSON-RPC的情况下，(以及许多协议，如XML-RPC、Soap，以及较新的协议，如GraphQL)根本没有以与HTTP良好匹配的方式使用HTTP。
从这个意义上说，它们不是HTTP应用程序，它们几乎将HTTP用作"隧道"。他们使用HTTP作为传输，但并没有"利用HTTP协议"。
对于这些情况，我认为http发出错误代码是不合适的。错误是在更高的级别上处理的，您可能总是想使用POST并在响应主体中传递错误信息时返回200。
那么回到你的问题：
- 是的，从HTTP的角度来看，无效的表单提交应该是4xx错误。密码a 401无效
- 不，这并不是在每个真实的用例中最明智的做法，比如浏览器和仅将HTTP用作传输的协议
- 但是，如果您正在开发一个基于REST的体系结构，或者您想按预期使用HTTP，那么这就是应该做的
浏览器在遇到422时是否应该有不同的行为？大概但对于一个好的用户体验来说，"有错误"通常是不够的。除了使用422更改浏览器的行为方式外，您可能还需要一种媒体类型，其中包含关于浏览器应如何将问题反馈给客户端的更具体的信息。