Allow 是什么
Allow 头列出目标资源支持哪些方法。它有两个强约束场景：405 响应必须携带它，OPTIONS 响应通常也会返回它（RFC 9110 §10.2.1，405 的要求见 §15.5.6）。对客户端与工具来说，这是不必逐个试错就能知道接口能力的方式。
什么时候会看到不一致
网关、框架与路由中间件都各自维护方法列表。如果 Allow 声明的与实际行为不符——例如声明支持某方法却返回 405——通常是路由重写、权限中间件或前置网关在其中改动了方法集合，而不是框架本身出了问题。
基本信息
| 名称 | Allow |
|---|---|
| 作用 | 枚举资源支持的方法 |
| 规范 | RFC 9110 §10.2.1，405 必须携带见 §15.5.6 |
| 常见场景 | 405 响应与 OPTIONS 响应 |
| 格式 | 逗号分隔的方法名列表 |
典型使用场景
- 客户端探测接口能力，避免盲目尝试后拿到 405
- 排查 405 与跨域预检失败
- 对接第三方系统时确认其支持的方法集合
- 比对网关声明与后端实际注册的路由
验证接口支持的方法
验证接口支持的方法
curl -si -X OPTIONS https://api.example.com/users | grep -i '^allow:'
# allow: GET, POST, HEAD, OPTIONS
curl -si -X PUT https://api.example.com/users | head -3 # 看 405 是否带 Allow状态与头部配合
| 场景 | 状态码 | 头部要求 |
|---|---|---|
| 方法不被支持 | 405 | 必须携带 Allow |
| 能力探测 | 204 或 200 | 通常携带 Allow |
| 跨域预检 | 204 | 携带跨域相关字段，而非 Allow |
| 资源不存在 | 404 | 不必携带 Allow |
Allow 与实际行为不符时，优先查路由重写与权限中间件，而不是先怀疑框架：这类不一致通常是中间环节改的。
部分网关默认拦截 OPTIONS 请求：需要显式放行，否则探测能力的客户端与工具会得到误导性的结果。
怎么用它做排障
当调用方报「接口 405」时，先用 OPTIONS 看声明了哪些方法，再直接用该方法发一次请求：如果声明与实际行为对不上，就顺着链路逐跳检查，从网关的转发规则一路查回后端路由注册，通常能很快定位到改动方法集合的那一环。
部分框架会把 HEAD 自动映射到 GET 处理：允许列表里出现 HEAD 并不一定代表后端单独实现过它。