把 flag 直接塞进 POST 请求体，参数服务器不一定认。提交这不是试试玄学，是参数协议层的事。

上周调一个内部接口，提交文档写着“支持 POST 提交 flag 参数”。试试我照着写了 flag=1，参数Content-Type 设成 application/x-www-form-urlencoded，提交结果返回 400。试试抓包一看，参数服务端框架把 flag 解析成了布尔值，提交但传过去的试试字符串 "1" 没被正确转换，直接抛了类型异常。参数换成 flag=true，提交通了。试试就这么个细节，文档没写，试了才知道。

参数到底放在哪一层

POST 提交参数，位置比 GET 灵活得多。可以塞在 URL query string 里，也可以放在 body 里，还能同时放。很多人以为 POST 就只能走 body，其实 POST /api?flag=1 完全合法，服务端照样能读到。区别在于：query string 里的参数会进日志、进浏览器历史、进代理缓存；body 里的相对干净。flag 这种控制开关，放 body 更合适，但得看框架怎么取。

用 Flask 举例，request.form.get('flag') 只读 body 里 application/x-www-form-urlencoded 或 multipart/form-data 编码的参数；request.args.get('flag') 只读 URL 里的。你要是把 flag 放在 JSON body 里，这两个都拿不到，得用 request.json.get('flag')。我见过有人用 request.values.get('flag')，那个是 form 和 args 的合并，JSON 仍然读不到。踩过一次坑，调了半小时才发现 Content-Type 写的是 application/json，但代码里用的是 request.form。

编码格式决定一切

三种常见 body 编码，行为完全不同。

application/x-www-form-urlencoded 是最传统的。浏览器表单默认就是这个，参数被 URL 编码后拼成 flag=1&name=test 的形式。服务端解析成键值对，所有值都是字符串。想传布尔值？自己转。想传数组？得用 flag[]=a&flag[]=b 这种约定，还得看框架认不认。

multipart/form-data 主要用于文件上传，但普通字段也能带。每个字段有独立的 boundary 分隔，解析开销比 urlencoded 大。flag 放这里没问题，就是有点杀鸡用牛刀。

application/json 是现代 API 的主流。body 是一个 JSON 对象，{ "flag": true} 过去，服务端反序列化后直接拿到布尔类型。干净、类型明确、嵌套结构随便传。但有个坑：有些老框架或者网关对 JSON body 的解析有大小限制，或者根本不解析，只透传。我遇到过 Nginx 默认不缓冲 JSON body，后端读的时候流已经空了，得加 proxy_request_buffering on。

一个真实翻车案例

之前对接某支付回调，对方文档说“POST 提交 flag 标识支付状态”。我这边用 Python requests 发 data={ 'flag': 'success'}，默认走 urlencoded。对方一直返回签名错误。后来发现他们签名算法是把 body 原始字节拿去做 HMAC，而我这边 requests 自动做了 URL 编码，空格变成 +，对方验签时没做同样的编码还原。改成 data=json.dumps({ 'flag': 'success'}) 并手动设 Content-Type: application/json，签名才对上。问题不在 flag 本身，在传输层的编码约定。

所以 flag 作为 POST 参数，能不能用、怎么用，取决于三件事：服务端从哪读、body 怎么编码、中间有没有代理改包。别信文档，抓包看原始请求。Wireshark 或者 Chrome DevTools 的 Network 面板，看 Request Payload 那一栏，比任何文档都准。

最后说个主观判断：flag 这种开关型参数，能用 JSON body 就别用 form。类型明确，嵌套方便，调试直观。urlencoded 适合简单表单，multipart 留给文件。选错了不是不能用，是给自己找麻烦。