PHP后端应通过请求头X-App-Lang获取语言标识，校验白名单后加载对应PHP语言文件（如/zh-CN.php），返回扁平化数组文案；禁用gettext/Symfony等重型方案，避免路径遍历与大小写错误。
PHP后端怎么给微信小程序返回多语言文案
微信小程序的多语言必须由前端控制语言偏好，PHP后端只负责按请求携带的语言标识（如 zh-CN、en-US）返回对应翻译内容。不能靠 PHP 的 setlocale() 或 gettext() 自动切换——小程序不传 Accept-Language，也不走浏览器标准协商流程。
实操建议：
- 小程序在请求头或 query 中显式传
lang=zh-CN（推荐放 header：X-App-Lang: zh-CN），避免 URL 泄露或缓存干扰 - PHP 接口统一读取该字段，校验是否在白名单内（如
['zh-CN', 'en-US', 'ja-JP']），非法值 fallback 到默认语言 - 翻译数据建议用扁平化 PHP 数组（非嵌套），例如：
$locales['zh-CN']['common.submit'] = '提交';，加载快、无扩展依赖 - 避免用 JSON 文件每次
file_get_contents() + json_decode()，可 APCu 缓存或直接 include 返回数组的 PHP 文件
怎么组织多语言文件结构才不乱
别把所有语言塞进一个大数组里。按模块拆分 + 按语言归档，后期维护和小程序按需拉取都更可控。
推荐结构：
立即学习“PHP免费学习笔记（深入）”；
/lang/ /zh-CN.php /en-US.php /ja-JP.php
每个文件返回关联数组，键名统一用英文+点号分隔（如 user.login.title），值为对应语言文案。PHP 加载时用 include 并校验返回值类型，防止文件出错导致整个接口挂掉。
注意点：
- 文件名必须严格匹配请求的
lang值，大小写敏感（zh-cn≠zh-CN） - 不要用
require_once：万一某语言文件缺失，应降级而非报致命错误 - 键名避免空格、斜杠、中文，否则小程序侧解析易出错；也别用动态拼接键名（如
$key = $module . '.' . $action），不利于静态扫描和翻译管理
小程序请求带 lang，PHP 怎么安全提取并使用
微信小程序调用 PHP 接口时，$_SERVER['HTTP_X_APP_LANG'] 是最干净的获取方式。比 GET/POST 参数更不易被篡改，也避免污染业务参数。
基础校验逻辑示例：
$lang = $_SERVER['HTTP_X_APP_LANG'] ?? 'zh-CN';
$lang = preg_replace('/[^a-zA-Z0-9\-_]/', '', $lang); // 清洗非法字符
$supported = ['zh-CN', 'en-US', 'ja-JP'];
$lang = in_array($lang, $supported) ? $lang : 'zh-CN';
常见坑：
- 没做字符清洗，攻击者传
lang=../../../etc/passwd%00可能触发路径遍历（如果后续用include "$lang.php"且未过滤） - 用
$_GET['lang']但没加 referer 或 sign 校验，中间人可篡改语言参数，造成信息泄露（比如把错误提示从中文变成英文暴露后端逻辑） - 忽略大小写，
EN-us直接导致文件未找到，返回空文案而不 fallback
为什么不用 gettext 或 Symfony Translation 组件
不是不能用，而是没必要。微信小程序的 i18n 是「服务端纯文案映射」，没有复数规则、日期格式化、占位符解析等复杂需求。
对比说明：
-
gettext需要编译.mo文件、配置环境、依赖系统 locale，PHP-FPM 容器里常缺失支持，调试成本高 - Symfony
Translation组件虽灵活，但引入整个symfony/translation包（含 YAML、CSV、XLIFF 解析器）对轻量接口是冗余，autoload 也拖慢响应 - 纯 PHP 数组方案：单文件加载
真有复杂需求（比如带复数的订单数量提示），再考虑用 intl 扩展的 MessageFormatter，但那是极少数场景。
多语言最难的从来不是“怎么切”，而是“谁来维护翻译键、怎么保证新增页面不漏翻、怎么让产品确认文案语境”。技术方案越简单，这些协作问题才越容易暴露和解决。
