Postman可通过form-data或x-www-form-urlencoded模式直接添加多余字段测试后端字段校验，关键在于验证其是否真正拦截而非静默丢弃；需结合响应状态码、错误信息及业务结果断言，并避免误用raw+JSON模式。
Postman怎么发带多余字段的表单请求
直接用 form-data 或 x-www-form-urlencoded 模式填入额外字段，不需要改代码或服务端配合。关键在于后端是否校验字段白名单——测试目的就是验证它“是否真的拒绝了非法字段”。
常见错误现象：发了多余字段但接口仍返回 200，误以为“没问题”，其实后端可能静默丢弃了字段，或根本没做字段校验。
-
form-data模式下，在 Body → form-data 表格里多加一行 Key/Value，比如已有username、email，再加一个hack_field→test123 -
x-www-form-urlencoded同理，在对应模式下手动添加键值对，Postman 会自动 URL 编码 - 别用
raw+ JSON 模式去模拟表单——Content-Type 不匹配，服务端大概率直接 415 Unsupported Media Type
如何断言“多余字段被正确拦截”
不能只看状态码。很多后端对非法字段返回 400，但有些返回 200 + 错误 message；更隐蔽的是返回 200 且不报错，但字段被忽略（逻辑漏洞）。
- 先确认接口文档约定的字段列表，把“不该出现的字段”列出来，例如
admin_flag、is_deleted - 在 Tests 中写断言，优先检查响应体是否含明确提示：
pm.test("Rejects unknown field", function () {<br> var jsonData = pm.response.json();<br> pm.expect(jsonData.code).to.eql(400);<br> pm.expect(jsonData.message).to.include("unknown field");<br>}); - 如果返回 200，需进一步验证业务结果：比如提交
price=999+ 多余discount=50，查数据库确认discount是否真的没入库
为什么 raw + JSON 不能替代表单测试
因为语义和解析路径完全不同。表单提交走的是 application/x-www-form-urlencoded 或 multipart/form-data 解析器，而 JSON 走的是 JSON 反序列化流程。两者字段校验逻辑往往分离，甚至由不同中间件处理。
Postman Mac版
下载
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
- 后端用 Spring Boot 的
@RequestParam接收表单字段，跟用@RequestBody接 JSON 是两套机制 - 某些框架（如 Django）对表单字段默认宽松（只取已声明字段），而 JSON 模式可能启用
strict=True报错——混用会导致漏测 - 文件上传场景下，
form-data是唯一支持二进制混合文本的格式，JSON 根本无法表达
环境变量+批量跑多个多余字段的技巧
手动一个个试效率低，尤其要覆盖 id、status、created_at 这类高危字段时，建议参数化驱动。
- 准备 CSV 文件，两列：
field_name、field_value，例如：admin_role, true<br>__proto__, {"pollute":"yes"} - 在 Pre-request Script 中读取当前行：
pm.variables.set("extra_field", pm.iterationData.get("field_name")); - Body → form-data 中 Key 填
{{extra_field}}，Value 填对应值；Headers 不用动 - Collection Runner 里勾选
Keep Variable values，方便失败后定位哪一行出问题
真正容易被忽略的是：有些后端对字段名做正则过滤（比如只允许字母+下划线），但没拦住 Unicode 零宽字符或大小写混淆（UsErNaMe），这类边界情况必须用实际 payload 跑，不能靠脑补。
