excel打开csv乱码是因缺少utf-8 bom头；需在header后、内容前用echo "\xef\xbb\xbf"手动输出bom，且不可有前置空格或调试输出，数据库已utf-8时勿重复转码。

导出CSV文件时Excel打开显示乱码，其实是BOM头没处理好

ThinkPHP默认输出的UTF-8内容不含BOM，但Windows版Excel（尤其是旧版本）依赖BOM头识别UTF-8编码。没有它，Excel就按ANSI（如GBK）解析，中文全变乱码。

解决方式不是改数据库字符集，也不是强制header设charset=utf-8——那对Excel无效。关键是在输出CSV内容前，手动添加UTF-8 BOM头字节序列 \xEF\xBB\xBF。

• 必须在echo或exit输出CSV内容前插入，不能在header之后、内容之前留空行或空格
• 不要用file_put_contents写临时文件再读取，容易因文件打开模式丢失BOM或引入额外换行
• 如果用了ob_start()缓冲，得在ob_end_clean()后、实际输出前写BOM，否则BOM会被缓冲截断

ThinkPHP 5.1/6.x 导出CSV时手动注入BOM的实操写法

别依赖框架自动编码转换，直接控制原始输出流。以下代码片段适用于控制器中导出逻辑：

header('Content-Type: text/csv; charset=utf-8');
header('Content-Disposition: attachment; filename="data.csv"');
// 关键：立即输出BOM，且不带任何前置空格或换行
echo "\xEF\xBB\xBF";
// 后续输出CSV内容（字段用英文逗号分隔，中文直接utf-8编码）
echo "姓名,城市,备注\n";
echo "张三,北京,\"含逗号的文本\"\n";
echo "李四,上海,正常\n";
exit;

注意：echo "\xEF\xBB\xBF"必须是第一个输出动作；如果前面有Log::info()、dump()或未关闭的var_dump()，BOM就失效。

为什么用iconv或mb_convert_encoding转UTF-8反而更糟

常见误区：看到乱码就对数据做iconv('GBK', 'UTF-8//IGNORE', $str)或mb_convert_encoding($str, 'UTF-8', 'auto')。这在ThinkPHP里大概率引发双重编码问题。

• 数据库查出的数据已是UTF-8（假设数据库和连接都设了utf8mb4），再转一次会把中文变成乱码字节序列
• mb_convert_encoding的'auto'参数不可靠，可能误判为ISO-8859-1，导致二次错误解码
• ThinkPHP的Db::query()或模型查询结果默认就是UTF-8字符串，无需额外转换

导出Excel（.xlsx）时不需要BOM，但要注意Writer类的编码配置

如果你用PhpSpreadsheet导出.xlsx，BOM完全无关——那是二进制格式。乱码通常源于单元格值没显式声明编码，或使用了过时的PHPExcel（已废弃）。

• 确保安装的是phpoffice/phpspreadsheet，不是phpexcel
• 写入中文前，确认$sheet->setCellValue('A1', '中文')即可，无需iconv预处理
• 若仍乱码，检查是否在Writer创建前调用了ini_set('default_charset', 'GBK')这类全局干扰项

BOM只对纯文本导出（CSV/TXT）起作用，而真实麻烦往往藏在“以为要转码”“以为要设header charset”这些多余动作里。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！