根本原因是字符串编码在链路中被错误解释：对象属性名本为UTF-8字节，却在某环节被当Latin-1或GBK等编码解读，导致字节曲解；需用mb_check_encoding验证原始编码，统一输出/存储环节的UTF-8声明，并从源头确保编辑器、IDE及IO接口均使用UTF-8。
PHP 8.0 中对象转数组后键名出现乱码（如 测试、娴嬭瘯 或问号 ??），根本原因不是“对象转数组”这一步出错，而是**字符串编码在链路中被错误解释**——对象属性名本身是 UTF-8 字节，但在某环节被当成了 Latin-1、GBK 或其他编码去解读，导致字节序列被曲解。
确认属性名原始编码是否为 UTF-8
PHP 内部不存储字符串编码信息，对象属性名本质是一串字节。先验证它本来就是合法 UTF-8：
- 用
mb_check_encoding($propName, 'UTF-8')检查返回true； - 用
bin2hex($propName)看前几个字节：中文“测试”应为e6b58be8af95（各三字节），若看到b2e2等两字节组合，说明已被误当 GBK 解释过。
排查对象转数组的触发点
常见转数组方式有三种，每种都可能引入编码干扰：
-
强制类型转换：
(array) $obj—— 安全，不改变字节，但要求属性为 public； -
json_encode + json_decode：
json_decode(json_encode($obj), true)—— 高危环节：若未加JSON_UNESCAPED_UNICODE，中文会被转成\u6d4b\u8bd5，再 decode 后仍是正确 UTF-8；但若中间被其他系统（如旧版 MySQL 连接）二次转码，就易出乱码； -
反射获取属性：
(new \ReflectionClass($obj))->getProperties()—— 属性名（$prop->getName()）始终是原始字节，但若后续拼接进 HTML 或写入非 UTF-8 文件，就可能被重解释。
输出或存储时统一声明编码
乱码总发生在“解释”环节，而非“生成”环节。关键是在下游明确指定编码：
PHP 8.5.12
下载
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
立即学习“PHP免费学习笔记（深入）”；
- 输出到浏览器：确保响应头含
Content-Type: text/html; charset=utf-8，HTML 中有<meta charset="utf-8">； - 写入文件：用
file_put_contents($file, $arr, FILE_TEXT | LOCK_EX)，避免二进制模式误写； - 存入数据库：MySQL 连接必须设
charset=utf8mb4，表字段用utf8mb4_unicode_ci； - 调试打印：用
var_export($arr)而非print_r($arr)，后者在 CLI 下可能受终端 locale 影响显示异常。
临时修复已乱码的键名（仅限诊断）
若已拿到乱码键名（如 "测试"），可尝试逆向还原（前提是知道被误读的编码）：
- 被当 Latin-1 读过一次：用
mb_convert_encoding($badKey, 'UTF-8', 'Latin1')； - 被当 GBK 读过：用
mb_convert_encoding($badKey, 'UTF-8', 'GBK')； - 不确定时，可用
mb_detect_encoding($badKey, ['UTF-8','GBK','BIG5','EUC-JP'], true)辅助判断（注意该函数不可靠，仅作参考）。
但更推荐从源头堵住：检查对象定义时属性名是否用 UTF-8 编辑器保存、IDE 文件编码是否设为 UTF-8、所有 IO 接口是否显式指定 UTF-8。
