安全能力重构 | D010篇 GET、POST与状态码分别代表什么

原创

陈看山
陈看山

安全诸子

2026年11月11日 22:00
上海

去阅读

模块一 · 安全能力重构365天 · 第2周 应用、API与数据基础

有些读者第一次用浏览器开发者工具看请求详情时，会被一排东西同时砸中：请求方法一栏写着 GET 或 POST，响应头里挂着 200、302、401、500，参数散在 URL 和请求体两处。看得见，但说不清各自负责什么。等真要排查“为什么登录提交后页面没跳转”“为什么下单接口返回 200 却没有生成订单”，就卡在这里。这篇就围绕 GET、POST 与状态码分别代表什么，把这三样东西的职责边界讲清楚，并用一条脱敏的四条调用链把它们串起来。

先把定位说清楚：它们是三层不同的约定

GET、POST 是请求方法，属于“客户端想对资源做什么”的声明；状态码是服务端在响应里给出的“这件事处理成什么样”的结论。两者不在一个层面，不能互相替代。请求方法回答的是意图，状态码回答的是结果。中间还有一层是请求体和 URL 参数怎么放，这决定了数据流向。

很多误解源于把这三层揉成一团。比如认为“POST 就是安全的”“200 就是成功”“GET 不能带参数”。这些说法都缺了前提。把它们分层看，问题会清晰很多：方法决定语义和可缓存性，状态码决定调用方下一步该做什么，参数位置决定这段数据会不会留在日志、历史记录和代理缓存里。

基于当前可见信息，这篇不涉及任何真实目标，只用一个虚构公司和脱敏模拟日志来说明因果关系。

它解决的核心矛盾：意图与结果的错配

真实排障里最常见的矛盾，是“我以为我发的是这个意图，服务端也回了成功，但结果不对”。三类错配反复出现。

第一类是方法用错导致语义漂移。用 GET 去触发有副作用的操作，浏览器、代理、爬虫都可能重放这个请求，你以为点了一次，实际执行了多次。用 POST 去查数据，则丢掉了缓存和可收藏 URL 的便利。

第二类是只看状态码不看响应体。状态码是粗粒度结论，200 只说明服务端成功处理了这次请求，不保证业务成功。很多系统把业务失败包装在 200 里，靠响应体的 code 字段区分，调用方如果只判 HTTP 状态码就会误判。

第三类是重定向与状态码混淆。302、303、307 都叫重定向，但对方法和请求体的处理不同，登录后跳转、下单后跳支付页，用错一个就可能把 POST 变成 GET，请求体直接丢失。

把 GET、POST 与状态码分别代表什么弄清楚，本质是让“意图—处理—结果”三段能对上号，而不是靠猜。

拆开看：方法、参数位置与状态码各自管什么

请求方法决定语义，不是决定安全

GET 的语义是获取资源，应当幂等、可缓存、可安全重放。参数放 URL 查询串里，因此会进入浏览器历史、服务端访问日志、代理缓存和 Referer。这不是“不安全”，而是“可见”。真正的敏感数据不该放在 URL 里，无论用什么方法。

POST 的语义是提交数据让服务端处理，通常不幂等、默认不缓存。参数放请求体，不进入 URL，但仍会进入服务端日志（如果记录了 body）和中间层。POST 不等于加密，也不等于防重放，防重放要靠幂等键、令牌或业务去重。

PUT、DELETE、PATCH 各有语义，日常排障见得多的是前两个，但判断标准一致：这个操作重复执行一次，结果会不会变。

状态码是给调用方的行动指令

按段理解比逐个背更实用。2xx 是服务端认为处理完成，其中 200 最常见，201 表示创建了资源，204 表示成功但无返回体。3xx 是需要调用方再走一步，301 永久、302 临时、304 命中缓存、307 和 308 强调保持方法不变。4xx 是调用方这边的问题，400 请求格式不对、401 未认证、403 已认证但无权限、404 资源不存在、429 触发限流。5xx 是服务端侧失败，500 未预期错误、502 上游返回异常、503 暂不可用、504 上游超时。

关键判断在于：4xx 通常不该原样重试，5xx 和 429 才考虑退避重试，3xx 要跟随后看最终落到哪个方法上。

参数位置决定数据流向和留痕

同样是提交用户名密码，放 URL 和放请求体，留下的痕迹完全不同。前者出现在访问日志的请求行里，后者出现在请求体里，是否记录取决于日志配置。理解这一点，才能解释“为什么日志里能看到搜索词却看不到密码”，也才能判断哪些字段该走哪条路。

放进四条调用链里看因果

用虚构公司的脱敏场景，按时间顺序拆输入、处理与输出。

注册链：用户填手机号和验证码，前端 POST 到注册接口，请求体带表单数据。服务端校验验证码，创建账号，返回 201 和用户 ID。若验证码错误，返回 400 并在响应体说明原因；若手机号已存在，很多系统返回 200 加业务错误码，这里就是“只看状态码会误判”的典型位置。

登录链：POST 提交凭据，服务端校验通过后下发会话，返回 302 跳转到首页，响应头带 Set-Cookie。浏览器跟随重定向，把 302 后的请求变成 GET。如果这里误用 307，方法会保持为 POST，跳转目标收到一个没有意义的 POST，行为就偏了。

下单链：POST 创建订单，请求体带商品与数量。服务端返回 201 和订单号。若库存不足返回 409 或 200 加业务码，取决于团队约定；若未登录返回 401，登录但无权购买返回 403。调用方要区分“该重新登录”和“该提示无权限”。

支付链：POST 发起支付，服务端调上游渠道，返回 200 加支付跳转地址，或返回 502 表示上游异常。这里 502 与业务失败要分开处理，前者可退避重试，后者不该重试。

顺着这四条链，GET、POST 与状态码分别代表什么就不再是名词解释，而是每一步“为什么这么发、回来这串数字意味着什么”的判断依据。

能力点对照：值不值得按这套方式理解

这张表的意思是：这套理解方式接入成本不高，真正花时间的是团队约定统一，而不是技术本身。

真实限制和容易做错的地方

一是别把方法当安全边界。GET 和 POST 都不提供机密性，传输安全靠 HTTPS，访问控制靠服务端鉴权。用 POST 掩盖敏感参数，只是让它不出现在 URL 里，日志和抓包照样能看到。

二是别把 200 当成功。业务失败包装在 200 里的系统很多，调用方要按约定解析响应体。反过来，服务端也别滥用 200 表达错误，会让监控和告警失真。

三是重定向要看清方法和请求体。涉及提交后跳转，优先确认目标方法是否被改写，否则会出现“提交成功但数据丢了”的怪现象。

四是不适用场景要承认。纯静态资源分发、简单内网脚本，不必强套完整语义；但一旦涉及多端调用、网关、缓存和审计，这套约定就是低成本高回报。

怎么接进现有流程

落地不需要大动作。第一步，把四条链画成调用图，标清每一步的方法、参数位置和期望状态码，形成一页 API 清单。第二步，在接口文档里固定“HTTP 状态码管传输与鉴权结果、业务码管业务结果”的边界，写清楚哪些码可重试。第三步，在日志规范里明确哪些字段允许进 URL，哪些必须进请求体且不记录。第四步，联调时用状态码分类决定前端提示文案，401 引导登录、403 提示权限、429 提示稍后再试，避免所有错误都弹“网络异常”。

代价是前期要统一约定，收益是排障时不再靠猜。这套东西适合需要多人协作、多端调用、要过审计的团队；个人小项目按需简化即可。

给读者的实践建议

找一个你手头正在维护的接口，做三件事：写出它的方法语义和是否幂等；列出它可能返回的全部状态码及对应处理动作；确认参数位置是否与日志、缓存策略一致。做完这三步，你对 GET、POST 与状态码分别代表什么就有了可操作的判断，而不是停留在名词层面。下一步动作是把这份结论补进团队的接口清单，让下一个人排障时少走一段弯路。