Postman 本身不限制文件名长度，真正拦住请求的是服务端解析层或 Web 容器（如 Tomcat 默认 header 行限 8192 字节），当超长 filename 导致 Content-Disposition 行溢出时，header 被静默截断或拒绝，后端获取 originalFilename 为空或乱码。
Postman 上传超长文件名时，boundary 和服务端限制谁先拦住你？
超长文件名（比如 256 字符以上）在 Postman 里能点选、能发出去，但大概率卡在服务端解析阶段——不是 Postman 不支持，而是它生成的 multipart/form-data 请求中，Content-Disposition 头里的 filename 字段被截断或触发编码异常，导致后端 MultipartFile.getOriginalFilename() 返回空、乱码，甚至直接抛 IllegalArgumentException。
关键判断点：先确认你的服务端是否做了原始文件名长度校验（Spring Boot 默认不校验，但很多团队会在 Controller 层加 if (filename.length() > 255)）。如果没做，那真正拦住你的其实是 HTTP 协议栈或 Web 容器（如 Tomcat 对 header 行长度默认限制为 8192 字节，超长 filename + boundary 可能撑爆单行）。
- Postman 本身不限制文件名长度，但 macOS/Linux 下文件系统对文件名上限通常是 255 字节（UTF-8 编码下中文占 3 字节，实际可写约 85 个汉字）
- 构造测试文件时，用 Python 一行生成：
touch $(python3 -c "print('a' * 255 + '.txt')")，别依赖 GUI 重命名——某些 Finder/Nautilus 会静默截断 - 发送后立刻检查响应体是否含
filename相关错误提示，而不是只看状态码；很多服务端对非法 filename 返回 400 但不带具体字段
为什么 filename 在 Postman 请求里显示正常，后端却拿到空字符串？
这是 multipart 边界和编码双重作用的结果。Postman 自动生成的 boundary 是随机字符串，当 filename 过长时，整行 Content-Disposition: form-data; name="file"; filename="..." 可能超过 Web 容器允许的单 header 长度，Tomcat 会静默丢弃该 header；或者 Spring 的 StandardServletMultipartResolver 在解析时因内部缓冲区不足，把 filename 值读成空。
验证方法：在 Postman 的 Console（View → Show Postman Console）里查看原始请求，搜索 filename=，确认它是否完整出现在 boundary 分隔块内；再对比服务端日志里打印的 request.getPart("file").getSubmittedFileName() 结果。
- 若 Postman Console 中 filename 完整，但后端为空 → 问题出在服务端解析层（检查
spring.servlet.multipart.max-file-size是否影响了整体解析，或自定义MultipartConfigElement的fileSizeThreshold设置过小） - 若 Postman Console 中 filename 已被截断（末尾是
..."或直接中断）→ 检查是否启用了代理（如 Charles/Fiddler），它们常对 header 做长度限制 - 避免使用双引号包裹超长 filename：某些旧版 Nginx 会拒绝含超长 quoted-string 的请求，改用
filename*=UTF-8''...编码格式（Postman 不自动启用，需手动构造 raw body）
application.properties 里调大 max-file-size 能解决超长文件名问题吗？
不能。这个配置只控制文件内容字节数上限，和文件名长度完全无关。混淆点在于错误信息里常出现 “exceeds its maximum permitted size”，让人误以为是文件太大，其实根源是文件名触发了底层协议解析失败。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
真正要调的参数取决于你的服务端技术栈：
- Spring Boot + Tomcat：在
application.properties加server.tomcat.max-http-header-size=16384（默认 8192），防止 filename 行被截断 - Spring Boot + Undertow：设
server.undertow.max-header-size=16384 - 若用 Nginx 做反向代理：必须同步调整
client_header_buffer_size和large_client_header_buffers，否则请求根本到不了 Spring - 代码层防御：Controller 中加
if (file.getOriginalFilename().length() > 255) { throw new IllegalArgumentException("filename too long"); }，比依赖容器更可控
Postman 里怎么批量测 100 个不同长度的文件名？
靠手动点选不现实。得用 Collection Runner + CSV 数据驱动，但注意：Postman 的 form-data 模式不支持在 CSV 里动态指定文件路径（安全限制），所以必须换思路——把文件名长度作为文本参数传，让服务端生成对应文件名的空文件再上传。
更可行的做法是：用 Pre-request Script 生成临时文件（仅限本地调试），或直接切到 raw 模式手写 multipart body（适合边界验证）：
- 新建请求 → Body → 选择
raw→ Content-Type 设为multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW - 粘贴完整 multipart 内容，其中
filename字段手动写满 256 字符，确保每段 boundary 后跟CRLF（Windows 换行符），否则解析失败 - 用 Newman 命令行跑自动化时，可通过
--folder指定含不同 length 的测试用例文件夹，比 CSV 更稳
真正容易被忽略的是：超长文件名测试必须搭配真实文件系统路径验证。比如上传后服务端保存为 /upload/xxx.txt，但 Linux ext4 对路径总长限制是 4096 字节，若目录嵌套深 + 文件名超长，file.transferTo() 会直接抛 FileNotFoundException，这个错误不会反映在 HTTP 响应里，只能查服务端日志。
