FrankenPHP中文乱码本质是UTF-8字节流在输出、捕获或显示环节被误解析为GBK/ISO-8859-1或LANG=C等编码，需逐层验证原始字节、强制locale为en_US.UTF-8、设置mb_internal_encoding('UTF-8')与响应头、禁用func_overload，并确保终端/编辑器以UTF-8解码。
FrankenPHP 1.1 中文乱码本质不是 FrankenPHP 自身缺陷，而是 UTF-8 字节流在输出 → 捕获 → 显示任一环节被错误当作 GBK、ISO-8859-1 或系统 locale（如 LANG=C）解析所致。修复需分层验证、精准干预，不靠盲目转码。
确认日志/响应原始字节确实是 UTF-8
肉眼看到“乱码”不可信，必须查真实字节：
- 在 PHP 脚本中对中文字符串做
echo json_encode($str, JSON_UNESCAPED_UNICODE);—— 正确输出应为"u4f60u597d"；若出现"\xc4\xe3\xba\xc3"则已是 GBK 编码 - 对生成的日志文件（如
app.log），用xxd app.log或 VS Code 以二进制模式打开，观察中文对应字节是否为e4 bd a0（“你”字 UTF-8 编码） - 若
bin2hex($str)返回c4e3bac3，说明 PHP 内部已按 GBK 处理，问题出在脚本执行环境
强制 FrankenPHP 运行时使用 UTF-8 locale
FrankenPHP 默认继承系统 locale，Linux 下 LANG=C 会禁用多字节支持，导致中文被丢弃或替换成 ?：
- 启动前运行
export LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8，再执行./frankenphp serve - 若用 systemd 管理，必须在
.service文件[Service]段显式声明：Environment="LANG=en_US.UTF-8" Environment="LC_ALL=en_US.UTF-8"
- 验证生效：在 PHP 中
var_dump(setlocale(LC_ALL, 0));应返回"en_US.UTF-8"
统一 PHP 内部与输出编码
避免 mb_strlen、json_encode 等函数因内部编码不一致出错：
- 在入口文件（如
public/index.php）最顶部第一行加入：mb_internal_encoding('UTF-8'); - 紧接着设置响应头（HTML 页面）：
header('Content-Type: text/html; charset=utf-8');或 API 接口：
header('Content-Type: application/json; charset=utf-8'); - 禁用
mbstring.func_overload（防止substr等被重载为多字节行为）：ini_set('mbstring.func_overload', 0);
检查日志查看与终端解码是否匹配
即使日志文件是纯 UTF-8，查看方式错误仍显示乱码：
- 终端（如 gnome-terminal、Windows Terminal）必须手动设为 UTF-8 编码，关闭“自动检测”
- 用
cat app.log时确保终端 locale 是 UTF-8；用less app.log时加环境变量：LESSCHARSET=utf-8 less app.log
- VS Code 打开日志后，右下角点击编码标识，选 “Reopen with Encoding” → “UTF-8”
- 绝对不要用 Windows 记事本打开日志——它会自动加 BOM 或误转码
不复杂但容易忽略
