密码合规校验API的HTTP状态码选型：密码不通过时是否应使用400？

首先明确讨论边界：以下结论完全基于你描述的场景——这是一个独立部署、核心功能就是接收密码输入、比对预设规则、返回校验结果的专门接口。对这个接口而言，不管密码最终是否符合策略要求，服务端都能正常解析请求、执行校验逻辑、拿到可预期的结果，不存在请求本身的解析/处理失败问题。

为什么在这个场景下用400等非200状态码不合适 #

• 400 Bad Request的核心适用场景是服务端无法理解或处理当前请求本身：比如请求体JSON格式错误、缺失必填请求头、参数语义完全无法解析，这类情况才符合400的语义。而你的校验接口中，不合规的密码和合规密码一样，都是可被正常读取、可被预期处理的合法输入，整个请求链路没有任何“服务端处理不了、理解不了”的问题。如果硬用400，会给客户端造成严重歧义：收到400的客户端通常会优先排查“是不是请求发错格式了、参数没传全”，而非“提交的密码不符合规则”。
• 422 Unprocessable Entity的适用场景是服务端完全理解请求语义，但因为业务原因无法完成本次请求要执行的核心操作：比如创号时密码不合规导致服务端没法完成账号创建、改密时旧密码错误导致没法完成密码更新，这类场景下422是合适的。但对你的独立校验接口来说，服务端的核心操作就是“跑一遍校验规则返回结果”，不管密码合不合规，这个操作都100%执行成功了，不存在“没法完成操作”的情况，因此422的语义也不匹配。

最适配这个场景的设计方案 #

对独立的密码合规校验接口，无论密码是否符合策略要求，统一返回200 OK，把校验结果全部放在响应体中，是语义最准确、客户端兼容性最好的选择：

• 要明确一个核心认知：HTTP状态码标记的是服务端对请求的处理流程是否执行成功，而非标记你提交的业务内容是否符合后续使用要求。就像你调用商品搜索接口，即使返回的搜索结果是空列表，只要服务端正常跑完了搜索逻辑，就该返回200，总不能因为没搜到结果就返回404或400——这个逻辑和密码校验接口的场景是完全共通的。
• 200的返回逻辑没有任何语义误导：客户端看到200就知道“请求已经被正常处理完成，直接读取响应体拿结果就行”，不需要额外排查请求格式、网络层面的错误。
• 结构化的响应体可以完全覆盖业务信息：你可以根据前端交互需求设计返回结构，比如合规场景返回{"validPassword": true, "satisfiedRules": ["长度≥8位", "包含字母+数字组合"]}，不合规场景返回{"validPassword": false, "reason": "too long", "violatedRules": ["长度超过20位上限"]}，前端可以直接用这些数据做实时的表单提示、规则点亮效果，完全不需要为校验不通过的场景单独写非200状态的处理分支。

特殊场景的状态码参考 #

如果接口设计不是纯粹的独立校验工具，而是和实际的写操作（比如创建账号、修改密码）绑定在一起——即接口接收到请求后，要先校验密码合规性，校验通过才会执行后续的写操作，校验不通过就终止写操作，这时候返回422是完全合适的：因为此时服务端的核心目标是完成“创建/修改密码”的操作，密码不合规属于“无法完成核心操作”的业务原因，完全匹配422的语义。 #

内容的提问来源于stack exchange，提问作者Eric L.