真正可靠判断文件编码只有两种方式：终端执行file -i查看charset=后内容，或用vs code右下角显示；php文件带bom会导致headers已发送或json失败，须存为utf-8 without bom。
确认文件真实编码不是靠右下角显示
PhpStorm右下角写的“UTF-8”只是猜测，尤其打开从Windows复制来的PHP或TXT文件时，大概率是GBK编码，但IDE误判成UTF-8，直接显示方块或问号。别信那个提示。
真正可靠的方式只有两个：
- 在终端执行
file -i your_script.php，看输出里charset=后面是什么（比如charset=gbk或charset=utf-8; with bom） - 用VS Code打开同一文件，右下角明确显示“GBK”“UTF-8”或“UTF-8 with BOM”，这个比PhpStorm可信得多
如果显示 charset=utf-8; with bom，说明文件带BOM（\xEF\xBB\xBF），这会导致PHP中 headers already sent 或JSON解析失败，必须重存为UTF-8 without BOM。
File Encodings三处必须同步设为UTF-8
进入 File → Settings → Editor → File Encodings（macOS是 PhpStorm → Preferences），以下三处缺一不可：
-
Global Encoding：设为UTF-8，影响所有新建项目默认行为 -
Project Encoding：设为UTF-8，覆盖Global，决定当前项目所有文件的读取/保存编码 -
Default encoding for properties files：也设为UTF-8，否则messages_zh_CN.properties这类资源文件必然乱码
注意：Transparent native-to-ascii conversion 勾选后，.properties里的中文会自动转成 \u4f60\u597d 形式——这是Java生态的正常机制，不是乱码，别因此误操作。
控制台输出乱码不能只改Console Encoding
Console Encoding 设置只控制IDE怎么解码输出字节流，不改变PHP实际输出的编码。单改它，90%会白忙。
必须联动三层：
- 系统层：终端执行
locale，确保有UTF-8；若LANG为空或为C，需运行export LANG=zh_CN.UTF-8并写入~/.bash_profile - JVM层：修改
bin/phpstorm.sh，在#!/bin/sh下**紧贴第一行**插入：export LANG=zh_CN.UTF-8和export LC_ALL=zh_CN.UTF-8 - PHP运行时层：脚本开头加
mb_internal_encoding('UTF-8');，并在终端执行php -r "echo mb_internal_encoding();"验证返回UTF-8
Run Configuration里加 -Dfile.encoding=UTF-8 是辅助项，不是替代方案。
已有乱码文件救回来：Reload as vs Convert to
对已打开但显示乱码的文件，右下角编码提示旁有两个按钮，作用完全不同：
- Reload as：仅让IDE用新编码重新读取文件内容，不改动磁盘上原始字节——适合误判编码场景（如GBK文件被当UTF-8打开）
- Convert to：把文件内容按当前编码解读后，再以目标编码重写保存——会永久修改文件，慎用于生产代码
操作前务必确认真实编码。比如 file -i 显示 charset=gbk，就右键 → Reload as → GBK；之后再统一设为UTF-8并 Convert to。
BOM、混用编码、Git自动转换、终端locale未生效——这些隐性干扰点往往藏在最后一步才暴露，调完File Encodings别急着关IDE，先重启Terminal标签页，再跑一次脚本验证输出。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
