分页导出不能直接用paginate()，因其仅执行带limit的单页查询并依赖可能缓存的count(*)，导致导出数据不全且总数不准；正确做法是复用相同查询条件，改用select()、column()或chunk()获取全量数据。
分页导出不能用 paginate() 直接套，否则只导出当前页数据，且 count 查询可能被缓存导致总数不准。
导出时为什么不能直接用 paginate()
导出是全量操作，不是分页展示。用 paginate(15) 会触发两条 SQL：COUNT(*) 和带 LIMIT 的主查询，后者只取 15 条——你导出来的永远只有一页数据。
- 即使你把
list_rows设成 999999，也受限于 MySQLmax_allowed_packet和 PHP 内存，容易崩溃 -
paginate()内部的 count 查询默认走缓存（尤其开启data_cache_type时），导出前刚删了几条，count 还是旧值 - 调用
$list->all()或$list->items()拿到的仍是切片后数组，不是原始全量结果
正确做法：复用查询条件，绕过分页逻辑
核心思路是「查条件不变，但不走分页」。用同一个 where、order 链式条件，改调 select() 或 column() 等方法拉全量数据。
- 先构建查询对象：
$query = Db::name('user')->where($map)->order('create_time desc') - 导出时直接执行：
$data = $query->select()（注意内存限制） - 若只要某几列，用
$query->column('id,name,email')减少数据体积 - 如数据量极大（>10 万行），必须加
chunk()分批处理：$query->chunk(500, function ($list) { /* 导出这批 */ });
如何让导出按钮保留搜索条件
导出链接里必须带上所有筛选参数（如 ?keyword=abc&status=1），否则点进去就查全表。关键不是靠 paginate() 的 query 参数，而是手动拼。
- 控制器里用
request()->param()拿全部 GET 参数，过滤掉page、per_page等分页相关键 - 生成导出 URL 时手动拼：
url('export', array_merge(request()->except(['page', 'per_page']), ['_t' => time()])) - 模板中导出按钮写成：
@#@#@#@#@#@#@#@#@#@0 - 不要用
location.href动态跳转再取$_GET，容易漏参数或被 XSS 注入
count 不准导致导出条数对不上怎么办
导出前显示的总条数（$list->total()）和实际导出数量不一致，八成是 count 被缓存了。这不是前端问题，得从查询源头控制。
- 禁用 count 查询缓存：在查询对象上调用
->cache(false)，例如：Db::name('user')->cache(false)->where(...)->count() - 更推荐方式：导出时不用
paginate()的 count，自己重算一次：$totalCount = Db::name('user')->where($map)->cache(false)->count() - 如果业务允许近似值，可提前把 count 结果存 Redis，设置较短过期时间（如 60 秒），导出时读缓存 + 加锁防并发更新
真正难的不是写出导出代码，而是确保「导出条件 = 列表条件 = count 条件」三者完全一致。任何一处用了硬编码、漏传参数、或缓存没清，都会导致用户投诉“明明列表看到 200 条，导出来只有 187 条”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
