Accept-Language 是客户端声明可接受语言的请求头，用于服务器返回对应语言版本的响应内容，而非翻译响应体；其生效依赖后端是否实现国际化支持及语言资源映射。
Accept-Language 是什么，为什么不能只填中文
Accept-Language 是客户端声明“我能看懂哪些语言”的请求头，不是让服务器“翻译成中文”，而是告诉它：如果响应体里有语言变体（比如多语言错误提示、本地化文案），优先返回哪个语言版本。服务器是否支持、是否真按这个头返回，完全取决于后端实现。常见错误是填 zh-CN 后发现响应没变化——大概率是接口压根没做国际化，或者只支持 en fallback。
Postman 中手动添加 Accept-Language 的三种方式
Postman 不会自动加这个头，必须显式配置：
- 在请求的
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 混用时容易踩的坑
这两个头常一起出现，但职责完全不同：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
-
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-USvsAccept-Language: zh-CN，看message或error字段内容是否变化 - 如果始终不变，打开 Postman 的
Console（View > Show Postman Console），确认请求发出时 header 确实携带了该字段，排除拼写错误（比如写成Accept-Languagee） - 某些服务会把语言偏好放在 cookie 或 query 参数里，此时
Accept-Language可能被忽略——得按文档要求改用其他方式传
真正起作用的从来不是头本身，而是后端有没有读它、有没有对应的语言资源、有没有正确映射到响应字段。很多团队只实现了 en 和 zh 两套文案，却忘了在代码里加 if (lang === 'zh-CN') {...} 分支。
