Postman本身不限制表单长度，所谓“参数被截断”99%是服务端解析器因缓冲区配置过小而静默丢弃超限数据，如PHP的max_input_vars、Node.js body-parser的limit、Nginx的client_max_body_size及Tomcat的maxParameterCount等，默认值低且常未重启生效。
Postman 本身不限制表单长度，所谓“参数被截断”，99% 是服务端解析器在读取请求体时主动丢弃了超出缓冲区的数据——而且不报错、不警告，只静默返回空 $_POST、空 req.body 或少掉最后几十个字段。
为什么 POST 表单会无声无息地丢数据
很多人以为 POST 没长度限制，其实只是“传输层”没限制，而“解析层”有硬门槛。比如：
- PHP 的
max_input_vars默认 1000，超过就直接砍掉后面所有变量（哪怕总数据才 200KB） - Node.js 的
body-parser默认limit: '100kb'，超限后req.body为{}，连日志都不打 - Nginx 的
client_max_body_size默认 1MB，超了直接返回413 Request Entity Too Large，但前端可能没捕获这个状态码 - Tomcat 的
maxParameterCount默认 10000，超了的参数会被静默丢弃（不是报错，是彻底消失）
这些配置全在服务端，Postman 发出去的数据完整无损，只是服务端压根没让它进到业务逻辑里。
快速定位是不是服务端截断
别急着改前端或重写请求，先验证是否真被服务端拦腰砍断：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 用 Postman 的
Console（View → Show Postman Console）看原始请求体，确认发送内容完整 - 在服务端加一行最原始的日志：PHP 打印
file_get_contents('php://input')，Node.js 打印Buffer.from(req.rawBody || '').toString()，对比是否和 Postman Console 一致 - 检查响应状态码：Nginx 返回
413、Spring Boot 返回400（exceeded max parameter count）、PHP-FPM 日志出现PHP Warning: Unknown: Input variables exceeded 1000 - 临时把表单字段减到 10 个以内再试，如果能通，基本锁定是
max_input_vars或maxParameterCount类配置
常见服务端配置怎么调
改完必须重启对应服务，否则无效：
- PHP：同时调大
post_max_size（如20M）、max_input_vars（如5000），并确认memory_limit足够（至少 2× post_max_size） - Nginx：在
http或server块中加client_max_body_size 20M;，然后nginx -t && systemctl reload nginx - Node.js（Express）：
app.use(bodyParser.urlencoded({ extended: true, limit: '20mb' }));和app.use(bodyParser.json({ limit: '20mb' })); - Tomcat：在
conf/server.xml的Connector标签里加maxParameterCount="5000"，注意不是maxPostSize（那是整个 body 大小）
更稳的绕过方式：别传超长表单
调大配置只是权宜之计，真正可靠的做法是避免让服务端解析海量扁平字段：
- 前端把数组转成 JSON 字符串：
JSON.stringify(goodsList)，作为单个字段（如data）提交 - 后端接收后手动解析：
$data = json_decode($_POST['data'], true);（PHP）或JSON.parse(req.body.data)（Node.js） - 如果含文件，改用
multipart/form-data，把 JSON 放在文本字段里，文件单独传——这样不受max_input_vars限制 - 对特别大的结构（如上万条记录），直接走分页 + 批量接口，别塞进一个 POST 里
服务端缓冲区配置是个“全局开关”，调太大可能引发 OOM 或被攻击利用；而 JSON 封装是“精准传递”，既绕过解析瓶颈，又保留语义完整性——这点最容易被忽略，但恰恰是最值得优先尝试的解法。
