Postman中文乱码主因是编码链路不一致，需检查服务端响应头是否含charset=UTF-8、强制Postman用UTF-8解码（Settings→General→勾选Force UTF-8 encoding）、设置环境变量POSTMAN_SET_CHARSET=utf-8，并区分文本与二进制响应类型。
Postman返回中文乱码，大概率不是Postman坏了，而是编码链路中某处没对齐——最常漏的是服务端响应头缺失 charset=UTF-8，或Postman自己没强制用UTF-8解码。
检查响应头是否真含 charset=UTF-8
Postman显示乱码时，先点开响应区的 Headers 标签页，找 Content-Type 字段。常见错误包括：
- 值是
application/json（没带;charset=UTF-8）→ Postman可能按ISO-8859-1或系统默认编码解析 - 值是
text/html;charset=utf-8（小写utf-8）→ 多数服务端接受，但部分严格框架（如Spring Boot 3+启用spring.web.resources.add-formatters=false时）会忽略小写 - 值是
application/json; charset = UTF-8（分号后有空格）→ 无效，RFC规范要求charset=必须紧贴，不能有空格
如果服务端是Spring Boot，确保Controller里写了：response.setContentType("application/json;charset=UTF-8")，而不是只设produces = "application/json"（后者不保证header生效）。
强制Postman用UTF-8解码响应体
即使服务端header正确，Postman仍可能因自动探测失败而误判编码。必须手动关掉“猜”：
- 右上角
Settings→General→ 找到Response language encoding→ 选UTF-8 - 务必勾选下方
Force UTF-8 encoding for responses（不勾选等于白设） - Mac版路径一致，但设置项名称略有差异：叫
Force UTF-8 response encoding
这个开关跳过所有自动编码识别逻辑，直接按UTF-8字节流解码。若服务端真返回GBK，会更乱——但现代API不该这样，所以这是安全默认。
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
用环境变量全局覆盖编码行为
当多个集合/请求都要统一处理，界面设置太费劲，推荐用环境变量：
- 点右上角
Manage Environments→Add -
KEY填POSTMAN_SET_CHARSET（全大写，少一个字母都不行） -
VALUE填utf-8（必须小写，UTF-8或Utf-8均无效） - 保存后，在请求右上角环境选择器中选中该环境
该变量优先级高于Settings里的全局设置，且对当前环境下的所有请求生效。适合团队协作时统一规范。
区分文本响应与二进制文件的处理方式
乱码还可能源于类型误判。比如下载CSV或Excel时点了 Pretty 视图：
- 文本类（
text/csv、application/json）：必须带charset=UTF-8，可用Pretty查看 - 二进制类（
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet、application/pdf）：Content-Type绝对不能带charset，否则Postman会强行当文本解析，导致Base64转义错乱 - 遇到疑似二进制响应却显示乱码，立刻切到
Body→ 点Download保存本地，再用对应软件打开验证——内容本身往往完好
真正容易被忽略的点是：服务端返回的Content-Type和实际字节流不匹配时，Postman不会报错，只会静默乱码。所以每次调接口前，先看Raw响应体开头几个字节是否可读，比依赖Pretty视图更可靠。
