必须调用ob_end_clean()清除输出缓冲区，否则HTML、空格或BOM会污染文件头，导致Excel/PDF/CSV乱码或损坏；CSV还需手动添加UTF-8 BOM（\xEF\xBB\xBF），Excel则依赖自身编码标识而非header charset。
ob_end_clean() 必须在导出前调用，否则缓冲区残留内容会污染 Excel/PDF/CSV 文件头，直接导致乱码或文件损坏。
导出前必须清空输出缓冲区
ThinkPHP 导出（尤其是用 PHPExcel、PhpSpreadsheet 或原生 fputcsv）时，如果前面有 echo、var_dump、调试日志、甚至意外的空格或 BOM，都会被写入响应体开头，破坏 Excel 的二进制结构或 CSV 的编码声明。
常见错误现象：
- Excel 打开提示“文件格式与扩展名不匹配”
- 中文显示为 或方框
- CSV 用 Excel 打开全是乱码，但用记事本看是正常的
实操建议：
- 导出方法第一行加
ob_end_clean()，不是ob_flush()，也不是ob_clean() - 确保该方法没被其他中间件、Hook 或日志组件提前输出内容
- 若用了 ThinkPHP6 的
Response返回StreamResponse，也要确认没触发过任何echo或模板渲染
header() 字符集声明对导出无效，别写
header('Content-Type: text/html; charset=utf-8') 对 Excel/PDF/CSV 导出完全无用，反而可能干扰客户端解析。这些文件格式靠自身 BOM 或内部编码标识，不是靠 HTTP header 的 charset。
立即学习“PHP免费学习笔记（深入）”；
正确做法：
- Excel（.xlsx）：无需 BOM，但生成时确保字符串本身是 UTF-8；
PhpSpreadsheet默认支持 UTF-8，不用额外转码 - CSV：必须在内容第一行前写入 UTF-8 BOM（
\xEF\xBB\xBF），否则 Excel Windows 版默认按 ANSI（GBK）解析 - 示例（CSV 导出开头）：
echo "\xEF\xBB\xBF"; fputcsv($fp, ['ID', '姓名', '电话']);
数据库字段含中文但导出仍是问号？查连接层是否真用了 utf8mb4
即使数据库表是 utf8mb4、字段也是 utf8mb4_unicode_ci，只要 PHP 连接 MySQL 时没生效 SET NAMES utf8mb4，SELECT 出来的数据在 PHP 内存里就是乱码字节，导出自然还是 ?。
验证方式：
- 在导出逻辑里加一行：
var_dump(Db::query("SELECT CHARSET('你好')")[0]['CHARSET(\'你好\')']);，应输出utf8mb4 - 若输出
latin1或utf8（非 mb4），说明连接字符集没生效
修复重点：
- ThinkPHP6 的
database.php中，'charset' => 'utf8mb4'是必要但不充分条件 - 必须确认连接建立后执行了
SET NAMES utf8mb4—— 可通过开启'trigger_sql' => true查日志，或手动在导出前执行Db::execute('SET NAMES utf8mb4') - 不要依赖配置自动触发，TP6 在某些部署模式下（如多库、自定义连接）不会透传 charset
上传文件名含中文、导出时又乱码？注意文件系统编码差异
Linux 服务器文件系统通常用 UTF-8，Windows 用 GBK；而 ThinkPHP 的 $file->move() 默认以 PHP 字符串（UTF-8）保存路径，但在 Windows 上实际写入磁盘时，若 PHP 运行环境未适配，会导致路径创建失败或文件名损坏。
典型表现：
- 上传成功但文件名变成
.pdf - 导出 ZIP 包里文件名乱码，解压后无法识别
实操建议：
- Windows 环境下，对文件名做一次
iconv('UTF-8', 'GBK', $filename)再传给move() - 导出 ZIP 时，用
ZipArchive::setArchiveComment()或第三方库（如chillerlan/php-zip）显式指定 UTF-8 路径标志位（ZIP_ENCODING_UTF_8） - 避免在路径中拼接用户上传的原始文件名，统一重命名（如 UUID + 后缀）可绕过此问题
echo 了一行、某个中间件提前写了 header、或者数据库连接初始化时漏掉了 SET NAMES。每次改完记得删掉所有临时 dump 和 echo，再试。 
