Postman 的 form-data 模式会自动设置带动态 boundary 的 Content-Type，手动设置易导致 boundary 不匹配、请求解析失败；Authorization 等其他头需手动添加，且须严格按规范填写。
不需要手动设置 Content-Type 请求头，Postman 在使用 form-data 时会自动生成带 boundary 的完整值；但其他认证或业务相关头（如 Authorization）必须手动添加，否则上传会失败。
为什么不能手动设置 Content-Type？
Postman 的 form-data 模式依赖动态生成的 boundary 字符串来分隔字段和文件数据。这个字符串每次请求都不同，且必须与请求体中的分隔符完全一致。手动填写 Content-Type: multipart/form-data; boundary=xxx 极易出错：
- 复制粘贴时多空格或换行，导致 boundary 不匹配
- 重复设置后覆盖 Postman 自动注入的正确 header，服务器解析失败
- 边界符若出现在文件内容中（极小概率），整个请求体结构崩溃
现象：服务器返回 400 Bad Request 或直接忽略文件字段，req.file 为 undefined（Node.js）或 MultipartFile 为空（Spring Boot）。
Authorization 和其他必要头怎么加？
只要不是 Content-Type，其他头都应在 Headers 标签页手动填写，尤其以下几类：
-
Authorization：值为Bearer <token></token>或Basic <credentials></credentials>，注意 token 是否过期 -
X-Request-ID、X-Correlation-ID等追踪头：部分后端强制校验，缺失会拒收 -
Accept：设为application/json可确保响应格式统一，避免返回 HTML 错误页 - 自定义业务头（如
X-Upload-Mode: async）：必须严格按接口文档大小写和命名填写
技巧：把常用头存为「Header Preset」，避免每次重复输入；环境变量建议用 {{auth_token}} 而非硬编码。
什么时候会看到自动生成的 Content-Type？
只有在你切换到 Body → form-data 后，发送请求前，点击 Headers 标签页才能看到 Postman 自动生成的那条：Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryabc123。它不可编辑，也不应删除——删掉反而会导致服务器无法识别格式。
- 如果你在
raw或binary模式下上传文件，Postman 不会自动加Content-Type，此时必须手动填，但这种模式不适用于标准表单上传 - 某些老旧网关或 WAF 会校验
Content-Type头是否存在，但不关心 boundary 值，此时空头比错头更安全
真正容易被忽略的是：上传多个文件时，每个 file 字段的 Key 名必须和服务端约定完全一致（比如后端要 avatar，你填成 image 就收不到），而这个错误不会报在 headers 上，得看响应体或日志才能定位。
