Accept请求头应填application/json等合法MIME类型，用于明确告知服务器期望的响应格式；其值需准确匹配服务端支持类型，否则可能导致返回非预期格式如XML或HTML。
Accept 请求头该填什么值才有效
Accept 是告诉服务器“我想要什么格式的响应”，不是可有可无的装饰项。如果后端接口做了内容协商（比如同时支持 application/json 和 application/xml），不设或设错 Accept，可能返回 XML 或 HTML 错误页，而不是你期望的 JSON。
常见合法值包括：
-
application/json：绝大多数 REST API 的首选，也是 Postman 自动 fallback 的默认值（但别依赖自动） -
application/vnd.api+json：JSON:API 规范专用 -
text/plain或*/*：慎用，可能触发服务端降级逻辑或返回非结构化内容
注意：Accept 和 Content-Type 无关——前者管“我要什么响应”，后者管“我发了什么请求体”。两者可以不同，比如发 application/json，但要求返回 text/plain（极少见，但合法）。
Postman 里填 Accept 头的实操位置和坑点
必须手动添加，Postman 不会自动帮你加 Accept，哪怕你 Body 选了 raw + JSON。
操作路径：
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
- 点击请求下方的
Headers标签页 - 在
Key栏输入Accept（大小写敏感，首字母大写） - 在
Value栏输入对应值，例如application/json - 确保右侧开关是开启状态（小眼睛图标没被遮住）
容易踩的坑：
- 拼错键名：写成
accept、ACCEPT或Accpet都无效 - 值里多空格：
application/json（末尾空格）会导致匹配失败 - 和
Content-Type混淆：删掉Content-Type行去“腾位置”给Accept，结果请求体被当成纯文本发送
Accept 和响应解析显示的关系
Postman 界面是否能自动美化 JSON 响应，不只看 Accept，更取决于响应头里的 Content-Type。但如果你明确设置了 Accept: application/json，而服务端仍返回 Content-Type: text/html，说明协商失败——这时候要查的是服务端逻辑或路由配置，不是 Postman 没设对。
调试建议：
- 发送后看响应头面板，确认
Content-Type是否如你所愿 - 如果响应体是乱码或原始字符串，先检查响应头
Content-Type，再反推Accept是否被尊重 - 配合
Tests脚本断言：pm.response.to.have.header("Content-Type", "application/json")，比肉眼判断更可靠
什么时候可以不设 Accept
当服务端不实现内容协商时，设了也白设。典型场景包括：
- 内部微服务间调用（协议约定死返回 JSON）
- Mock Server 或本地 Spring Boot 默认配置（未启用
@ResponseBody多媒体类型协商） - 接口文档明确写“仅返回 JSON”，且历史响应始终一致
但上线前压测或联调阶段，建议始终显式设置 Accept。因为一旦服务端升级引入协商逻辑，没设的请求可能突然行为异常，而这种问题在线上很难快速定位。
