rest多语言国际化核心是客户端决定语言，服务端通过accept-language头识别并响应，默认兜底；错误信息用语义化code+参数解耦，资源文件按bcp 47命名；数据格式统一（utf-8、iso 8601、整数金额）；openapi扩展支持sdk自动生成。
REST 接口支持多语言国际化，核心是把“语言选择权交给客户端”，服务端只做识别、匹配和响应，不硬编码提示文本。关键不在翻译本身，而在结构设计、资源分离和协议协同。
用 Accept-Language 头自动识别语言偏好
客户端在请求中带上标准 HTTP 头，服务端据此决定返回哪种语言的消息：
-
推荐方式：使用
Accept-Language: zh-CN,en-US;q=0.8，服务端按权重顺序匹配可用语言包 -
兜底逻辑：若头缺失或不匹配任何已配置语言，返回默认语言（如
en-US） -
注意点：不要依赖 URL 参数（如
?lang=zh）作为主路径，它可作备用，但不符合 REST 原则且不利于缓存
错误响应结构必须支持语言解耦
错误信息不能写死在代码里，而要通过键值对 + 多语言资源文件管理：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 响应体中只传语义化错误码（如
"code": "USER_NOT_FOUND"）和可选参数（如"params": ["123"]） - 实际提示文本（
message）由服务端根据当前语言动态注入，或由前端基于 code 查本地资源包 - 资源文件命名需规范：
messages_en-US.properties、messages_zh-CN.properties，内容示例：
user.not.found=The user with ID {0} does not exist.
统一数据格式与编码，避免解析歧义
语言切换不该影响数据结构本身，所有基础格式必须稳定、无歧义：
-
字符编码：强制响应头声明
Content-Type: application/json; charset=utf-8 -
时间字段：一律用 ISO 8601 UTC 格式，如
"created_at": "2026-09-25T05:30:00Z" - 金额字段：用整数表示最小货币单位（如分），避免浮点精度问题
-
语言标识：严格采用 BCP 47 标准（如
zh-Hans、pt-BR），不简写为zh或pt
配合 OpenAPI 定义提升多语言 SDK 兼容性
接口契约一旦标准化，就能驱动工具链自动生成各语言客户端，减少手动适配成本：
- 在 OpenAPI spec 中为 error code、message 字段添加
x-localizable: true扩展标记 - 用
description字段提供英文说明，同时在外部 i18n 文件中维护其他语言的对应描述 - 生成 SDK 时，工具可自动把 JSON 字段名（snake_case）映射为各语言习惯命名（如 Python 的
user_name→ Go 的UserName）
