导出接口卡死主因是PHP执行超时和内存不足，需依次检查max_execution_time、memory_limit、fastcgi_read_timeout等配置，并采用分块查询、内存优化、异步导出等方案。
导出接口卡死时，先查 max_execution_time 是否被触发
php 导出逻辑（尤其是 excel 生成）常因执行超时直接中断，但不报错，只表现为页面“一直转圈”。这时不是前端问题，而是脚本在服务端被 max_execution_time 强制终止——默认 30 秒，对导出万行数据完全不够。
实操建议：
- 在导出入口脚本顶部加
set_time_limit(0)（慎用，仅限可信后台任务）或设为合理值如set_time_limit(300) - 检查 php.ini 中的
max_execution_time，CLI 和 Web SAPI 可能不同，用phpinfo()确认当前生效值 - 若用 Nginx + PHP-FPM，还需同步调大
fastcgi_read_timeout，否则 Nginx 会在 PHP 还没超时前就断开连接，导致前端收不到响应
memory_limit 不足会导致导出中途 OOM，但错误日志可能被静默丢弃
生成 Excel（尤其用 PhpSpreadsheet）时内存飙升极快：10 万行 × 20 列轻松突破 512MB。而 PHP 默认 memory_limit 常为 128M 或 256M，超限后进程被 kill，Apache/Nginx 返回 500，但浏览器只显示加载中——因为响应头都未发出。
实操建议：
- 导出前用
ini_set('memory_limit', '1G')临时扩容，比改 php.ini 更灵活 - 避免一次性加载全部数据到内存：用
PDO::FETCH_CURSOR或分块fetch，配合gc_collect_cycles()主动回收 - 启用
PhpSpreadsheet的内存优化模式：Settings::setMemoryCacheSize('512MB')并设置setReadDataOnly(true)（如无需公式）
前端请求未设超时，会掩盖真实后端失败
不少项目用 axios 或 fetch 触发导出，但没配 timeout，导致后端已 504 或崩溃，前端仍傻等。用户看到“加载中”，其实后端早已无响应。
实操建议：
-
axios请求必须加timeout: 300000（5 分钟），并监听onDownloadProgress判断是否真有数据流下来 - 不要用
window.location.href直接跳转导出 URL——无法捕获超时或 5xx 错误；改用fetch+response.blob()+URL.createObjectURL()，才能统一处理异常 - 导出接口返回前，先写个轻量预检：比如
SELECT COUNT(*) FROM xxx WHERE ...，若数据量 > 10 万，直接返回{ code: 400, msg: "数据量过大，请联系管理员" }
异步导出不是银弹，但能绕过大部分超时与内存瓶颈
同步导出本质是把所有压力堆在单次请求生命周期里，而真正稳定的方案是拆开：前端提交任务 → 后端落库/发队列 → 前端轮询状态 → 完成后提供下载链接。这样每个环节都可控。
实操建议：
- 用 Redis 存任务状态（
task:{id}:status）和文件路径（task:{id}:file），比数据库轮询更轻量 - 队列任务里用
set_time_limit(0)和大memory_limit安全，因为不走 Web SAPI - 前端轮询间隔别太密（如 2s 起步），加退避策略，避免压垮接口；状态字段至少包含
pending/processing/failed/done
