根本原因是输出流与接收端编码协商失败；PHP需确保文件UTF-8无BOM，CLI终端设UTF-8编码，Web端header+meta双声明，服务器禁用gzip等缓冲，避免误用转码函数。
PHP echo 或 print 实时输出中文变问号或方块
根本原因不是 PHP 本身，而是输出流（stdout）和接收端（浏览器 / 终端 / curl）之间的编码协商没对上。PHP 脚本里用 header('Content-Type: text/html; charset=utf-8') 只影响 HTTP 响应头，对 CLI 模式或 ob_flush()+flush() 实时推送无效。
常见现象：echo "你好"; 在浏览器里显示为 ，在终端里是空格或乱码；用 curl -N http://localhost/test.php 看到的是 UTF-8 字节但没解码。
- 确认脚本文件本身是 UTF-8 无 BOM 编码（编辑器里检查，别用 Windows 记事本保存）
- CLI 模式下，终端需支持 UTF-8：Linux/macOS 一般默认 OK；Windows CMD 需先执行
chcp 65001，PowerShell 则要设$OutputEncoding = [System.Text.UTF8Encoding]::new() - Web 模式下，除了
header()，还要确保 HTML 的<meta charset="utf-8">存在，且放在<head>最前面
ob_flush() + flush() 实时输出中文失败
这两个函数只是把 PHP 输出缓冲区内容推给 Web 服务器（如 Apache/Nginx），但服务器自身还有缓冲层，且可能做字符转码。中文乱码往往卡在这一步之后。
- Apache：确保
mod_deflate未启用（它会压缩并破坏流式响应），或在.htaccess加SetEnv no-gzip 1 - Nginx：必须关闭
gzip和fastcgi_buffering，配置段加gzip off; fastcgi_buffering off; - PHP 层补救：在
ob_start()前加mb_internal_encoding('UTF-8');，避免多字节函数误判编码 - 每次输出后加
usleep(10000);（10ms），防止 TCP 包过小被合并，导致浏览器收不到完整 UTF-8 序列
用 iconv() 或 mb_convert_encoding() 强制转码反而更乱
这类函数只改字符串内容，不改传输协议层面的声明。如果原始字符串已经是 UTF-8，再用 iconv('UTF-8', 'UTF-8', $str) 不仅多余，还可能因参数错误触发静默失败。
立即学习“PHP免费学习笔记（深入）”；
- 先用
mb_detect_encoding($str, ['UTF-8', 'GB2312', 'GBK'], true)查原始编码，别凭感觉猜 - 只在确定源编码非 UTF-8 时才转：比如读取旧 GBK 文件，用
mb_convert_encoding($content, 'UTF-8', 'GBK') - 避免对
$_GET/$_POST直接转码——现代 PHP（7.2+）已默认按default_charset解析，改php.ini中的default_charset = "UTF-8"更安全
浏览器 DevTools 显示“UTF-8”但内容仍是乱码
说明响应头和实际字节不一致。打开 Network 面板，点开请求 → Headers → Response Headers，确认 Content-Type 是 text/html; charset=utf-8（注意分号后有空格）。如果看到 charset=gbk 或压根没这个 header，问题就在这里。
- PHP 中
header()必须在任何输出前调用，包括空格、BOM、echo "" - 用
headers_sent($file, $line)检查是否已发 header，返回 true 就说明前面有不可见输出 - 某些框架（如 Laravel）会自动设置 header，此时手动
header()会警告，应改用框架提供的响应构造方式
curl -i http://localhost/test.php 看原始响应头和 body 字节，再用 xxd 或 hexdump -C 检查中文是否为合法 UTF-8 编码（如“你好”应为 e4-bd-a0 e5-a5-bd）。只要字节对了，问题一定出在接收端解码环节。 
