PHP源文件必须是UTF-8无BOM编码，否则PHP 8.5.5会因BOM触发“headers already sent”错误，导致Content-Type失效和乱码；需用VS Code确认并保存为UTF-8（非UTF-8 with BOM），Linux下用file -i验证charset=utf-8。
PHP源文件本身是UTF-8无BOM吗？
这是最常被忽略的第一环。PHP 8.5.5 不会自动跳过 BOM，只要文件开头存在 \xEF\xBB\xBF（UTF-8 BOM），header() 就会立刻报 headers already sent，后续所有 Content-Type 设置都失效，浏览器只能靠猜编码——大概率显示乱码。
- 用 VS Code 打开 PHP 文件，右下角看当前编码，点它 → “Reopen with Encoding” → 依次试
GBK、ISO-8859-1、UTF-8，哪个能看清代码结构，就选哪个重开 - 确认可读后，点右下角编码 → “Save with Encoding” → 严格选
UTF-8（注意不是UTF-8 with BOM） - Linux 下验证：
file -i your_script.php输出应为charset=utf-8，不含with bom - 别信编辑器“自动识别”，有些文件明明是 GBK，VS Code 却标成 UTF-8，保存即损坏
HTTP响应头和HTML meta是否同步声明UTF-8？
PHP 8.5.5 对 header 发送时机更敏感，echo、空格、甚至文件末尾换行符都可能触发“headers already sent”。只写 header('Content-Type: text/html; charset=utf-8') 不够，必须确保它在任何输出之前执行。
-
header()必须放在 PHP 文件最顶部，且前面不能有任何空白、echo、print、HTML 标签，甚至不能有空行 - HTML 中
<meta charset="UTF-8">要放在<head>最开头，紧贴<head>标签后，不能在<title>后面 - 用
curl -I http://yoursite/test.php检查响应头，确认返回的是Content-Type: text/html; charset=utf-8，不是charset=iso-8859-1或缺失 charset - CDN 或反向代理（如 Nginx）可能覆盖 PHP 的 header，此时只能靠 HTML
meta保底，但优先级低于 header
读取外部文件或数据库时编码是否显式指定？
PHP 8.5.5 默认不假设外部数据是 UTF-8。file_get_contents() 读 GBK 文件、PDO 查询未设 charset、mb_strlen() 未设 encoding 参数，都会导致结果错乱。
- 读本地中文文本：先用
file_get_contents()读二进制，再用mb_convert_encoding($content, 'UTF-8', 'GBK')转，别依赖自动检测 - MySQL 连接必须显式设 charset：
$pdo = new PDO($dsn, $user, $pass, [PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"]);，注意是utf8mb4，不是utf8 - 创建库表时用
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，否则 emoji 和生僻字存不全 - 用
mb_*函数时，第三个 encoding 参数不能省：mb_substr($str, 0, 10, 'UTF-8')，否则默认用mb_internal_encoding()值，而该值未必已设
GD生成验证码或图像时字体与编码是否匹配？
PHP 8.5.5 的 GD 绑定更严格，imagettftext() 遇到编码或字体问题不再静默降级，而是直接出方块、问号或 Warning。
立即学习“PHP免费学习笔记（深入）”；
- 字体路径必须是绝对路径：
__DIR__ . '/fonts/simhei.ttf'，相对路径在 CLI/Web 下行为不一致 - 字体必须真实支持中文 Unicode 区段（U+4E00–U+9FFF），用
fontforge查，别信文件名 - 待渲染的字符串必须已是 UTF-8：
$text = mb_convert_encoding($text, 'UTF-8', 'auto')，从 POST 或 DB 来的数据尤其要转 - 调用
imagettftext()前务必用imagefilledrectangle()清空背景，否则旧像素残留干扰文字渲染
