PHP导出Excel/CSV全攻略：选型、性能优化与避坑指南

1. 从业务场景到技术选型：为什么你的导出方案总踩坑

做PHP开发这几年，几乎每个项目都逃不过表格导出这个需求。后台管理系统的订单列表、用户报表、财务对账单，甚至是前端页面上一个“一键导出”的按钮，背后都牵着一套导出逻辑。很多人第一次接到这个需求时，第一反应是：不就是把数据库里的数据循环一遍，写到文件里吗？真做起来才发现，坑一个接一个——数据量大了内存直接爆掉，导出的Excel在WPS里打开乱码，数字变成科学计数法，日期变成一串####，更离谱的是有的文件打不开，或者下载下来是空文件。这些我都踩过，所以这篇博客准备把这几年做导出功能的经验和坑一次性讲清楚。

先给这篇文章定个调：核心目标是让你拿到需求后，能快速选型、快速实现、快速上线，并且知道出了问题该往哪个方向排查。内容会围绕最常见的两种路线展开——使用PhpSpreadsheet这类成熟类库做功能完整的导出，以及用CSV或原生XML方式做轻量级导出。这两种方案对应的场景完全不同，选错了后面全是事。

先说结论，再做对比分析。如果你要导出的是几万行以内、格式要求不高、只要数据能看能统计的数据，CSV导出是最快最省事的方案；如果你的数据要带样式、要合并单元格、要有多个Sheet、要设置列宽和冻结窗口，那就老老实实用PhpSpreadsheet；如果你要做的是复杂报表模板，每次都从零构建样式会累死人，那就用模板填充或者前端导出方案。下面展开讲。

1.1 Excel导出的常见业务需求与实现路线

Excel导出这个需求的本质，是把服务端的数据按某种约定的格式交给用户，让用户可以在Excel、WPS这类软件里继续编辑和分析。拆开看，业务需求大概分三类：

• 纯数据导出：就是把查询结果原样输出，行对行、列对列，不带任何样式，用户拿到手自己再排版。这类需求最常见，订单明细、日志列表、通讯录都属于这一类。
• 带格式导出：要求导出文件里有表头颜色、列宽设置、冻结首行、自动筛选、货币格式、日期格式等。财务对账单、销售报表、工资条这类需求比较典型。
• 复杂模板导出：文件里不光是数据，还包含固定格式的合同条款、审批流程、签名区域，数据只是填到指定位置。这类需求最麻烦，一般会先用Excel做好模板，再通过程序往模板里填数据。

清楚了需求类型，再选实现路线。CSV方案适合第一类，PhpSpreadsheet方案适合前两类，模板填充方案适合第三类。

1.2 主流PHP导出方案的横向对比

从这张表能看出来，大部分项目的导出需求都能落到前两行。接下来的正文部分，我会重点讲PhpSpreadsheet的完整实现流程，因为这是功能最全、项目里用得最多的一条路线；CSV方案虽然简单，但也有不少细节值得讲，我会单独开一节。

2. 快速上手PhpSpreadsheet：环境准备与第一个导出脚本

PhpSpreadsheet是目前PHP社区里最主流的Excel操作类库，前身是PHPExcel。PHPExcel已经停止维护很久了，新的项目一律用PhpSpreadsheet。它能读写xlsx、xls、ods、csv等格式，支持样式、公式、图表、图片，功能非常全面。

2.1 环境要求与Composer安装

PhpSpreadsheet要求PHP 7.2及以上版本，如果你用的是PHP 8.0、8.1、8.2，完全没问题。还需要开启php_zip、php_xml、php_gd这几个扩展，其中zip用于读写xlsx压缩包，xml用于解析文件结构，gd用于处理图片。安装方式很简单，项目根目录下执行：

bash复制composer require phpoffice/phpspreadsheet

如果Composer安装速度慢，可以把源切换到国内镜像：

bash复制composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/

安装完成后，在一个独立测试脚本里先确认环境没问题：

php复制<?php
require 'vendor/autoload.php';

use PhpOffice\PhpSpreadsheet\Spreadsheet;
use PhpOffice\PhpSpreadsheet\Writer\Xlsx;

$spreadsheet = new Spreadsheet();
$sheet = $spreadsheet->getActiveSheet();
$sheet->setCellValue('A1', 'Hello World');
$writer = new Xlsx($spreadsheet);
$writer->save('test.xlsx');
echo 'OK';

运行后如果生成了一个test.xlsx文件，说明环境和类库都没有问题。这里要提醒一句：很多人把Composer安装和引入搞混，直接把类库文件拷到项目里用，这种做法极度不推荐，Composer的自动加载机制能让依赖管理省心很多，后续升级类库版本也是一个命令的事。

2.2 一个最小的导出脚本：从写入数据到浏览器下载

第一个正式脚本我们就做一件事：从数据库查询订单数据，导出成一个带表头的xlsx文件。为了不把篇幅浪费在数据库连接上，我用数组模拟数据源，你替换成实际查询语句即可。

php复制<?php
require 'vendor/autoload.php';

use PhpOffice\PhpSpreadsheet\Spreadsheet;
use PhpOffice\PhpSpreadsheet\Writer\Xlsx;

// 模拟从数据库查出的数据
$orders = [
    ['单号' => 'ORD20250601-001', '客户' => '张三', '金额' => 1280.50, '下单时间' => '2025-06-01 10:23:11'],
    ['单号' => 'ORD20250601-002', '客户' => '李四', '金额' => 564.00, '下单时间' => '2025-06-01 11:02:45'],
    ['单号' => 'ORD20250601-003', '客户' => '王五', '金额' => 2899.90, '下单时间' => '2025-06-01 14:37:02'],
];

$spreadsheet = new Spreadsheet();
$sheet = $spreadsheet->getActiveSheet();

// 设置表头
$headers = ['订单单号', '客户名称', '订单金额', '下单时间'];
foreach ($headers as $colIndex => $header) {
    $column = chr(65 + $colIndex); // A, B, C, D
    $sheet->setCellValue($column . '1', $header);
}

// 填充数据
$rowIndex = 2;
foreach ($orders as $order) {
    $sheet->setCellValue('A' . $rowIndex, $order['单号']);
    $sheet->setCellValue('B' . $rowIndex, $order['客户']);
    $sheet->setCellValue('C' . $rowIndex, $order['金额']);
    $sheet->setCellValue('D' . $rowIndex, $order['下单时间']);
    $rowIndex++;
}

// 设置列宽
$sheet->getColumnDimension('A')->setWidth(20);
$sheet->getColumnDimension('B')->setWidth(12);
$sheet->getColumnDimension('C')->setWidth(12);
$sheet->getColumnDimension('D')->setWidth(22);

// 输出到浏览器
header('Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet');
header('Content-Disposition: attachment;filename="orders_' . date('YmdHis') . '.xlsx"');
header('Cache-Control: max-age=0');

$writer = new Xlsx($spreadsheet);
$writer->save('php://output');
exit;

这段代码核心逻辑就四步：创建Spreadsheet对象、往单元格写数据、设置基本样式、用Writer输出。我见过不少人在输出到浏览器这一步卡住，最典型的错误是文件下载后损坏或乱码。出现这个问题的原因绝大多数是：在header输出之前，脚本里已经有HTML输出、BOM头或者空白字符。PHP的header函数要求在任何输出之前调用，哪怕多一个空格都可能报错。

还有个细节值得注意，我用了chr(65 + $colIndex)来计算列名，这在列数少于26的时候没问题。如果列数超过26，就不能用这套算法了，需要用PhpOffice\PhpSpreadsheet\Cell\Coordinate::stringFromColumnIndex()这个方法来转换，它能正确处理Z列之后的AA、AB列。代码可以改成：

php复制use PhpOffice\PhpSpreadsheet\Cell\Coordinate;

$column = Coordinate::stringFromColumnIndex($colIndex + 1);

2.3 导出所需的正确HTTP响应头

响应头是导出功能最容易被忽略又最容易出错的环节。很多人写完代码发现下载下来的文件无法打开，第一反应是类库用错了，实际是响应头不对。正确的响应头一般包含这几项：

php复制header('Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet');
header('Content-Disposition: attachment;filename="export.xlsx"');
header('Cache-Control: max-age=0');
header('Content-Length: ' . filesize($filePath)); // 如果是保存文件后输出

关于Content-Type，xlsx文件的标准MIME类型是application/vnd.openxmlformats-officedocument.spreadsheetml.sheet，老版本的xls是application/vnd.ms-excel，CSV是text/csv。如果类型设置错，有些浏览器会直接预览成乱码，或者提示文件格式异常。

Content-Disposition里的filename参数，建议用英文加日期格式，比如export_20250601.xlsx。如果你非要用中文文件名，需要做URL编码处理，否则部分浏览器会乱码：

php复制$fileName = '订单导出_20250601.xlsx';
header('Content-Disposition: attachment;filename="' . rawurlencode($fileName) . '"');

实测下来，用rawurlencode处理中文文件名在主流浏览器里都正常。还有一个容易被忽略的点：save('php://output')之前，确保没有开启输出缓冲。如果框架里开启了ob_start，需要先ob_end_clean()清掉缓冲区，不然输出内容会被混入文件流。

3. 大数据量导出的性能优化与内存控制

PhpSpreadsheet的一个典型瓶颈是内存占用。一万行的数据量还好，十万行的时候默认配置下内存直接起飞，上百MB甚至GB级别都很常见。很多新手在这里卡住，以为是数据查询太慢，其实问题出在类库默认把所有单元格都缓存在内存里。

3.1 为什么数据一多就内存溢出

PhpSpreadsheet内部有一个Cell Collector机制，默认情况下所有单元格对象都会保存在内存数组中。每个单元格对象本身有属性开销，加上坐标解析、样式引用，哪怕只有一个纯文本值，内存开销也可能达到几百字节到几KB。十万行乘以十列，就是一百万个单元格，内存占用轻松突破几百MB。如果服务器内存限制是128M或256M，直接翻车。

这里有个概念要澄清：内存溢出跟数据查询方式有关系，但核心瓶颈往往在写入端。就算你用游标一万一万地查，只要把所有数据塞进Spreadsheet对象，内存照样爆。所以优化思路要放在Writer和Cell缓存上。

3.2 用临时文件/流式写入来控制内存

常见的优化手段有几种，按推荐程度排序：

• 启用单元格缓存到文件：在创建Spreadsheet之前，先设置缓存方式，把单元格数据缓存到临时文件或Redis里，内存只保留索引信息。
• 用Xlsx Writer的setPreCalculateFormulas(false)：禁止写入时自动计算公式，如果表格里没有公式，这一步能省不少内存。
• 使用临时文件保存结果：输出到php://output时Writer还是会在内存里构建整个文件，可以先保存到临时文件再输出，配合readfile发送文件。
• 改用CSV方案：CSV是纯文本流式写入，一行一行处理，内存占用几乎可以忽略不计。

以单元格缓存为例，PhpSpreadsheet从1.16版本起引入了新的缓存API，文档里推荐的做法是使用Settings::setCache()传入Psr16Cache实现类。不过这个配置在不同版本里写法略有差异，老版本用的是setCacheStorage方法。我建议先看您安装的类库版本再选择对应写法：

php复制use PhpOffice\PhpSpreadsheet\Settings;
use PhpOffice\PhpSpreadsheet\CachedObjectStorage\Memory;
use Psr\SimpleCache\CacheInterface;
use Symfony\Component\Cache\Adapter\FilesystemAdapter;
use Symfony\Component\Cache\Psr16Cache;

// 使用文件缓存
$cache = new Psr16Cache(new FilesystemAdapter('phpspreadsheet', 0, sys_get_temp_dir()));
Settings::setCache($cache);

这行配置放在new Spreadsheet之前，它会把单元格对象缓存到系统临时目录，内存占用会从几百MB降到几十MB。代价是执行时间变长，因为要频繁读写临时文件。以我的实际测试来看，五万行乘以八列的数据，不开缓存内存约350MB，开启文件缓存后降到60MB左右，写入时间从4秒增加到9秒。内存和速度之间需要权衡，生产环境里我倾向于给导出脚本单独开一个队列进程，配置更高的内存限制，保持写入速度。

还有一个很实用的配置是关闭自动计算，如果你的表格里只有数据没有公式，写入前加这一行：

php复制$writer = new Xlsx($spreadsheet);
$writer->setPreCalculateFormulas(false);

这样Writer在写入时不会去挨个计算单元格公式的值，能省下不少CPU和内存。

3.3 分批查询与游标遍历的配合

数据源层面也有优化空间。很多人的SQL是一口气SELECT * FROM orders WHERE ...，几百万行数据直接全部加载到PHP数组里再写入Excel。这种做法必须改。推荐方式是用数据库游标分批读取：

php复制$pdo = new PDO('mysql:host=localhost;dbname=test', 'user', 'password', [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
]);

$stmt = $pdo->prepare('SELECT id, order_no, customer, amount, created_at FROM orders WHERE created_at >= ? ORDER BY id');
$stmt->execute([$startTime]);

// 每次只读5000行写入一次，并释放引用
$rowIndex = 2;
while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
    $sheet->setCellValue('A' . $rowIndex, $row['id']);
    $sheet->setCellValue('B' . $rowIndex, $row['order_no']);
    // ... 其他列
    $rowIndex++;

    // 每5000行强制刷新一次输出，释放PHP内部缓存
    if ($rowIndex % 5000 === 0) {
        // 如果使用异步队列，可以把当前进度存到Redis，支持断点续传
        unset($row);
    }
}

PDO::FETCH_ASSOC配合while循环，比一次性fetchAll要省内存，mysqlnd驱动默认也是一行一行从服务端拉取的。配合前面说的单元格文件缓存，十万行导出在256M内存限制下是可以跑完的。如果你用的是Laravel框架，cursor()方法本质上就是这个思路。

4. 常见格式问题的排查与处理

格式问题占导出排障的六成以上，而且这些问题在网上搜出来的答案往往互相矛盾，因为原因可能来自完全不同的环节。我按自己实际遇到的情况，把高发问题集中列出来。

4.1 文件名乱码与编码问题

文件名乱码可能出现在两个位置：浏览器下载时显示的文件名，以及Excel打开时的文件内容乱码。前者是响应头编码问题，前面讲过了，用rawurlencode解决。后者要分情况：xlsx文件本身就是UTF-8内部存储，一般不会乱码；CSV文件最容易乱码，因为Excel默认用GBK编码打开CSV，而PHP这边输出的是UTF-8。

解决CSV中文乱码最简单的方法，是在输出内容前加一个BOM头：

php复制header('Content-Type: text/csv; charset=UTF-8');
echo "\xEF\xBB\xBF"; // UTF-8 BOM

加了这个三字节的BOM，Excel才会正确识别CSV文件是UTF-8编码。不加的话，Excel会用本地默认编码（简体中文系统就是GBK）打开，中文全变乱码。还有一个办法是把内容转成GBK再输出，但涉及到转码损耗，不推荐。

4.2 长数字和日期被Excel自动转换

导入导出的经典问题：订单号、身份证号、银行卡号这类长数字，导出后用Excel打开显示成科学计数法，或者后几位变成0。原因是Excel对于超过11位的数字自动转成科学计数法，超过15位则精度丢失。

解决方案有几种，最简单的是把长数字单元格的格式设置成文本：

php复制$sheet->setCellValueExplicit('A2', $order['order_no'], \PhpOffice\PhpSpreadsheet\Cell\DataType::TYPE_STRING);

setCellValueExplicit可以显式指定数据类型为字符串，Excel打开后左上角会有绿色小三角标记，提示这是文本格式的数字。如果不用这个函数，直接在setCellValue里传字符串，PhpSpreadsheet会智能判断数值并转成数字，同样会踩科学计数法的坑。

日期显示成####的问题则是列宽不够，日期字符串长度超出列宽时Excel会用一串井号代替。这时候检查列宽设置即可，同时建议把日期字段写成字符串格式：

php复制$sheet->setCellValue('D' . $rowIndex, date('Y-m-d H:i:s', strtotime($order['created_at'])));

默认情况下PhpSpreadsheet会把符合日期格式的字符串转成Excel日期数值，这样在单元格里设置日期格式时才能正常显示。如果你不想转，同样用setCellValueExplicit配合DataType::TYPE_STRING强制按字符串处理。

4.3 XLSX和CSV在浏览器中的下载差异

很多人在本地用命令行运行脚本生成文件一切正常，一到浏览器下载就各种问题。这里有几个实践经验：

• 如果文件下载后大小为0字节，检查脚本末尾有没有exit，以及输出缓冲有没有被框架接管，必要时ob_end_clean()后重新刷新。
• 如果下载的文件扩展名是xlsx但打开提示损坏，优先怀疑Content-Type与Writer输出格式不匹配，或者文件内容里混入了HTML、错误日志、PHP警告信息。
• 如果是通过Nginx + PHP-FPM部署，偶尔出现文件下载中断，检查Nginx的client_max_body_size配置值是否过小，以及fastcgi的output_buffering设置。

4.4 多表合并导出的实现思路

热搜词里有个“vue多个表格导出一个excel”，这在前后端分离项目里很常见。前端有多个表格需要合并到一个Excel文件的不同Sheet中，后端实现思路也简单：同一个Spreadsheet对象里创建多个工作表，分别填入数据。

php复制$spreadsheet = new Spreadsheet();

$sheet1 = $spreadsheet->getActiveSheet();
$sheet1->setTitle('订单数据');
// 写入订单数据...

$sheet2 = new \PhpOffice\PhpSpreadsheet\Worksheet\Worksheet($spreadsheet, '客户数据');
$spreadsheet->addSheet($sheet2);
// 切换到第二个工作表并写入数据
$spreadsheet->setActiveSheetIndex(1);
$sheet2->setCellValue('A1', '客户ID');

这里有个容易踩的坑：new Spreadsheet()时默认自带一个工作表，如果你直接循环创建新表往里面填数据，不处理默认表，最后导出的文件里会多出一个空白的Sheet。建议代码里把默认表重命名并当成第一个Sheet使用，或者最后删除默认表：

php复制$spreadsheet->removeSheetByIndex(0);

前端对接时，一个接口返回一个xlsx文件流即可，前端用responseType: 'blob'接收，然后用以下方式触发下载：

javascript复制const blob = new Blob([response.data], { type: 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet' });
const url = window.URL.createObjectURL(blob);
const link = document.createElement('a');
link.href = url;
link.download = 'export.xlsx';
link.click();
window.URL.revokeObjectURL(url);

这样无论合并了多少个表格，前端拿到的都是一个文件，用户感知就是“一键导出整个目录”。

5. 进阶经验：真实项目中的几个坑与填补方案

5.1 导出任务耗时过长时的异步化思路

有人问，为什么导出接口一调就超时？答案很简单：数据量大了，PHP进程要花几十秒甚至几分钟构造文件，而HTTP请求一般默认30秒就超时了。同步导出的方式在大数据量场景下不可行。

我的做法是把导出任务丢进消息队列，比如Redis队列或者RabbitMQ。用户点击导出后，接口只返回一个任务ID，后台任务生成文件并存储到OSS或本地磁盘，前端轮询任务状态，任务完成后返回文件下载地址。这个流程和Excel本身没有关系，但它是支撑大数据量导出的关键架构决策。

用Redis做一个简单的队列，代码大概是这样的：

php复制// 投递任务
$taskId = uniqid('export_', true);
$redis->lpush('export_queue', json_encode([
    'task_id' => $taskId,
    'user_id' => $userId,
    'filters' => $filters
]));

后台Worker进程消费队列，生成文件后把文件路径写到Redis，前端轮询时根据任务ID获取下载链接。这里的核心原则是：用户不需要等待文件生成完成才得到响应，只需要知道任务进度就够了。

5.2 与前端框架配合时的边界情况

如果项目用的是Vue或React，前端通常会用封装好的request方法发起导出请求。这里有个很容易踩的问题：axios默认会把响应数据当JSON解析，即使你后端设置了正确的Content-Type，axios也可能因为响应拦截器的缘故把blob类型处理错。

正确的axios写法：

javascript复制axios.get('/api/export/orders', {
    params: filters,
    responseType: 'blob'
}).then(response => {
    const disposition = response.headers['content-disposition'];
    // 从content-disposition中解析文件名
    const fileName = decodeURIComponent(disposition.split('filename=')[1]);
    const blob = new Blob([response.data]);
    const link = document.createElement('a');
    link.href = URL.createObjectURL(blob);
    link.download = fileName;
    link.click();
});

responseType: 'blob'必须显式声明，不然axios会尝试把返回内容当字符串处理，最后下载的文件没法打开。另外一个常见问题是跨域请求（热搜词里有“php跨域+jsonp”），导出接口如果和前端不在同一个域名，需要在后端处理CORS，尤其是要允许Content-Disposition响应头被前端读取：

php复制header('Access-Control-Allow-Origin: https://your-frontend.com');
header('Access-Control-Expose-Headers: Content-Disposition');

不设置Access-Control-Expose-Headers，JavaScript是读不到响应头里的文件名的，前端只能硬编码下载文件名。如果你遇到下载下来的文件名总是不对，优先检查这一行。

5.3 模板导出与样式设置的实用套路

模板导出的特点是样式复杂度高，但每次填充的数据结构相对固定。我的做法是提前用Excel设计好模板，存到项目的storage/templates目录，然后用PhpSpreadsheet加载模板再填充：

php复制$template = new \PhpOffice\PhpSpreadsheet\Reader\Xlsx();
$spreadsheet = $template->load('storage/templates/salary_template.xlsx');
$sheet = $spreadsheet->getActiveSheet();

// 在模板指定位置填充数据
$sheet->setCellValue('B2', $employee['name']);
$sheet->setCellValue('B3', $employee['department']);
$sheet->setCellValue('B4', $employee['base_salary']);

这种方式的优点是样式完全在Excel里维护，设计师或运营同学可以直接改模板，不用动代码。缺点是模板和代码之间形成了隐式约定，一旦模板结构调整，代码可能静默填错位置。我的经验是：模板里需要填充的单元格用醒目的填充色标注，并在代码里写注释说明每个单元格对应哪个字段，交付时写清楚模板维护规范。

关于样式设置，我再分享几个高频操作：

• 设置表头背景色：$sheet->getStyle('A1:D1')->getFill()->setFillType(Fill::FILL_SOLID)->getStartColor()->setARGB('FFFFC000');
• 设置字体加粗：$sheet->getStyle('A1')->getFont()->setBold(true);
• 冻结首行：$sheet->freezePane('A2');
• 自动筛选：$sheet->setAutoFilter('A1:D100');

这些代码在PhpSpreadsheet里都有明确的类方法，用Composer安装后可以直接查源码，不用死记。

5.4 导出结果的正确性校验

最后讲一个很多人忽略的环节：导出功能的自动化测试。我接手过一个项目，某次数据库字段调整后，导出报表里的“实付金额”列一直显示0，但因为没人看Excel的每个单元格，问题潜伏了整整两个星期，直到财务那边投诉才发现。

数据导出虽然不如核心业务流程那么“关键”，但一旦出错，外部影响很直接。我的建议是：

• 在测试环境用固定的少量数据执行导出，然后用PhpSpreadsheet的Reader重新读取文件，断言关键单元格的值。
• 对大文件导出，至少确认行数和表头正确，比如读取$sheet->getHighestDataRow()来判断行数是否和查询结果一致。
• 把导出接口纳入接口测试的范围，不光是看返回的HTTP状态码，还要验证响应头里的Content-Type和Content-Disposition。

我自己后来写导出功能，都会单独写一个测试用例，用一条真实订单数据导出，再读取文件倒数第二行，确保最后一个数据点没有丢失。这套流程跑一遍基本能防住八成以上的回归问题。

6. 换成CSV后的体验差异与适用边界

前面很多内容都在讲PhpSpreadsheet，这里单独说说CSV。不少人一提导出就想上PhpSpreadsheet，但CSV在很多场景下才是更合理的选择。

CSV的本质是纯文本文件，用逗号分隔字段，换行分隔记录，任何文本编辑器都能打开，Excel和WPS也都能识别。它的优点是几乎没有内存压力，可以一行一行往文件里写，不需要在内存里维护对象树。

一个典型的CSV导出代码：

php复制header('Content-Type: text/csv; charset=UTF-8');
header('Content-Disposition: attachment;filename="orders.csv"');
echo "\xEF\xBB\xBF";

$output = fopen('php://output', 'w');
fputcsv($output, ['订单单号', '客户名称', '订单金额', '下单时间']);

while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
    fputcsv($output, $row);
}
fclose($output);

这段代码在几十万行数据下都不会内存爆炸，因为fputcsv是逐行写入，数据流直接从MySQL流向浏览器，PHP本身只是做了一次格式转换。对比PhpSpreadsheet动辄几百MB的内存占用，优势很明显。

当然CSV的短板也明显：没有多个Sheet，不能合并单元格，不能设置列宽，样式一概不支持，而且数字格式控制需要自己拼字符串，比如金额的小数点位数。所以业务要求“要Excel那样带格式”的时候，CSV就不合适了。

我自己的选型逻辑很简单：

• 数据量大（超过5万行）且不需要复杂格式 → CSV
• 数据量中等（几千到几万）且需要基本格式 → PhpSpreadsheet，开文件缓存
• 数据量小（几百行）但需要复杂样式 → PhpSpreadsheet模板导出

这个标准不一定适合所有项目，但可以作为初始参考，根据实际情况调整。

最后再分享一个小技巧：不管用哪种方案，导出文件生成完成后，最好在文件头部或最后一列加一个生成时间戳和查询条件说明，方便用户对照数据是否是最新的。比如CSV文件第一列加一个“导出时间”，或者xlsx表格右下角加一行“生成时间：2025-06-01 15:00”。这个小习惯帮我在后期排查“用户说数据不对”的工单时省了很多事，因为通常聊两句就能确认是数据时效性问题还是代码bug。