用 fputcsv 导出订单日志最稳：需清除输出缓冲、转 GBK 编码、设 CSV 响应头；仅需样式或多 Sheet 时才用 PhpSpreadsheet；务必脱敏敏感字段并排查 BOM/编码问题。

PHP 导出订单日志到 Excel 用 fputcsv 最稳

别一上来就装 PhpSpreadsheet，90% 的订单日志导出需求，纯文本 CSV 就够了——兼容所有 Excel 版本、生成快、内存占用低、无依赖。只要日志是数组结构（比如从数据库查出的 $orders），直接用 PHP 原生 fputcsv 写文件最可靠。

常见错误：用 echo 拼接 CSV 字符串再用 header 输出，容易因 BOM、编码、换行符导致 Excel 打开乱码或格式错乱。

• 必须用 fopen('php://output', 'w') 直接写响应流，避免缓冲区干扰
• 务必在 fputcsv 前调用 mb_convert_encoding($row, 'GBK', 'UTF-8')（Windows Excel 默认读 GBK）
• 字段含逗号、换行、双引号时，fputcsv 会自动加引号和转义，不用手动处理
• 导出前加 ob_end_clean() 清除已有输出，否则 Excel 打开提示“文件格式不匹配”

header('Content-Type: text/csv; charset=GBK');
header('Content-Disposition: attachment; filename="order_log_' . date('Ymd_His') . '.csv"');
$fp = fopen('php://output', 'w');
fputcsv($fp, ['订单号', '用户ID', '金额', '状态', '创建时间'], ',', '"');
foreach ($orders as $row) {
    $csvRow = [
        $row['order_no'],
        $row['user_id'],
        $row['amount'],
        $row['status_text'],
        $row['created_at']
    ];
    fputcsv($fp, array_map(function($v) { return mb_convert_encoding($v, 'GBK', 'UTF-8'); }, $csvRow), ',', '"');
}
fclose($fp);

用 PhpSpreadsheet 只在需要样式或多 Sheet 时才上

如果导出要带颜色标题、冻结首行、数字千分位、超链接（比如订单号跳转后台页面）、或者把日志按状态拆成多个 Sheet，那必须用 PhpSpreadsheet。但它吃内存，1 万条记录就可能 OOM，且默认 UTF-8，Windows Excel 打开中文仍是乱码——得手动设编码。

• 安装后不要用 IOFactory::createWriter($spreadsheet, 'Xlsx') 直接输出，先保存临时文件再 readfile()
• 中文显示必须调用 $sheet->getDefaultStyle()->getFont()->setName('微软雅黑')，否则默认是「等线」，部分系统不认
• 日期字段要用 PHPExcel_Style_NumberFormat::FORMAT_DATE_DATETIME 格式化，否则导出的是时间戳数字
• 大日志量导出务必启用 setReadDataOnly(true) 和 setPreCalculateFormulas(false) 省内存

导出报错 “headers already sent” 怎么快速定位

这个错误不是你代码问题，而是前面有不可见输出：可能是 config.php 文件末尾多了空格、UTF-8 BOM 头、或 error_log() 被开启并输出到页面。别猜，直接看报错行号前的文件。

• 用 git grep -I $'\xEF\xBB\xBF' 检查项目里有没有 BOM 文件（尤其 Windows 编辑器保存的 PHP 文件）
• 在导出逻辑最开头加 if (headers_sent($file, $line)) { die("Headers sent in $file on line $line"); }
• 确认 display_errors = Off 在生产环境生效，否则 Notice 级错误也会触发输出
• 框架用户注意：Laravel 的 dd()、ThinkPHP 的 halt() 如果残留在中间件或配置里，必炸

订单日志含敏感字段（如手机号、地址）必须脱敏再导出

导出接口常被运营反复刷，一旦没过滤，原始日志里的 phone、real_name、address 就直接裸奔到 Excel 里。这不是功能问题，是合规红线。

• 永远不要从原始 $order 数组直接取值，先过一遍脱敏函数：maskPhone($row['phone'])、substr($row['real_name'], 0, 1) . '**'
• 数据库查日志时就用 SQL 脱敏：CONCAT(LEFT(phone,3), '****', RIGHT(phone,-7)) AS phone
• 如果用 ORM（如 Laravel Eloquent），在 Model 里定义 getPhoneAttribute 访问器，确保所有地方读到的都是脱敏后值
• 导出前做一次 array_filter($orders, function($o) { return $o['status'] !== 'deleted'; })，过滤已删除/异常订单