Accept-Language 是客户端声明可接受语言的请求头，用于服务器返回对应语言版本的响应内容，而非翻译响应体；其生效依赖后端是否实现国际化支持及语言资源映射。

Accept-Language 是什么，为什么不能只填中文

Accept-Language 是客户端声明“我能看懂哪些语言”的请求头，不是让服务器“翻译成中文”，而是告诉它：如果响应体里有语言变体（比如多语言错误提示、本地化文案），优先返回哪个语言版本。服务器是否支持、是否真按这个头返回，完全取决于后端实现。常见错误是填 zh-CN 后发现响应没变化——大概率是接口压根没做国际化，或者只支持 en fallback。

Postman 中手动添加 Accept-Language 的三种方式

Postman 不会自动加这个头，必须显式配置：

Postman 12.27.7

Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。

下载

• 在请求的 Headers 标签页，Key 栏输入 Accept-Language，Value 栏填 zh-CN,zh;q=0.9,en;q=0.8（注意用英文逗号分隔，q 表示权重）
• 若整个 Collection 都需要统一语言偏好，可在 Presets > Manage Presets 里新建一个预设，Key-Value 固定为 Accept-Language: zh-CN，后续一键应用
• 需要动态切换时，在 Pre-request Script 中写：pm.request.headers.add({key: 'Accept-Language', value: 'en-US'});

和 Content-Type 混用时容易踩的坑

这两个头常一起出现，但职责完全不同：

• Content-Type 描述你发给服务器的数据格式（比如 application/json），影响请求体解析
• Accept-Language 只影响服务器返回的响应内容语言（比如错误信息是 “用户名不存在” 还是 “User not found”），不改变 JSON 结构或字段名
• 误把 Accept-Language 当作 Content-Type 去填 application/zh 之类非法值，会导致服务器忽略该头甚至报 400
• 某些 API 文档会把 Accept-Language 写成可选，实际却是必填（尤其 SaaS 类多租户系统），不填就默认返回英文，且无任何提示

验证 Accept-Language 是否生效的实操方法

光看状态码没用，得检查响应体里的具体文案：

• 发一个已知会返回语言相关提示的请求，比如登录失败、参数校验不通过
• 对比两次请求的响应体：Accept-Language: en-US vs Accept-Language: zh-CN，看 message 或 error 字段内容是否变化
• 如果始终不变，打开 Postman 的 Console（View > Show Postman Console），确认请求发出时 header 确实携带了该字段，排除拼写错误（比如写成 Accept-Languagee）
• 某些服务会把语言偏好放在 cookie 或 query 参数里，此时 Accept-Language 可能被忽略——得按文档要求改用其他方式传

真正起作用的从来不是头本身，而是后端有没有读它、有没有对应的语言资源、有没有正确映射到响应字段。很多团队只实现了 en 和 zh 两套文案，却忘了在代码里加 if (lang === 'zh-CN') {...} 分支。