管理员在订单列表能看到几百条记录，点 Export CSV 下载出来却只有表头。这种情况别先怀疑 Excel，CSV 已经生成，只是导出使用的数据源没有取到行。

先看导出请求带了哪些筛选条件

打开 Network，点击导出，保存请求参数。UI Grid 的筛选、选择方式和 namespace 会一起传给导出控制器。页面上看似已经清空筛选，用户 bookmark 里可能仍保存着日期、store 或状态条件。

用 Reset Filters 后再导一次，并换一个从未打开过该 Grid 的管理员账号测试。如果新账号正常，优先清理或重建该用户的 UI bookmark，而不是改订单表。

SELECT bookmark_id, user_id, namespace, identifier
FROM ui_bookmark
WHERE namespace = 'sales_order_grid';

不要直接删除所有人的 bookmark。先备份并只处理故障用户和对应 namespace，否则别的后台列表布局也会被重置。

有自定义列时检查导出用的collection

页面数据有时来自插件改过的 DataProvider，而导出请求走另一条 collection 链路。自定义 join 使用 inner join、重复 alias 或只在普通请求下注入条件，都可能让导出 collection 变成空集。

临时去掉自定义列并不能证明字段本身有问题，要对照生成 SQL。记录普通 Grid 和 export 请求的 where、join、store scope 差异，尤其检查批量选择参数是 selected 还是 excluded。

异步导出还要看消费者和文件权限

部分版本或扩展会把大批量导出交给消息队列。请求立即成功但文件为空或迟迟不生成，就检查对应 consumer、队列记录和 var/export 的写权限。Web 节点与 consumer 节点使用不同共享目录时，也会发生任务写完但下载节点找不到文件。

修复后分别验证：无筛选导出、按日期筛选、只勾选两单、排除一单以及非超级管理员。CSV 行数应该和 Grid 当前条件一致，自定义金额列也要核对一两条原始订单，避免“有数据了”却导出错行。