Laravel 的 paginate() 方法内部已自动处理 LIMIT 和 OFFSET，若手动调用 limit() 会导致分页逻辑错乱，引发页数虚高、空数组报错（如 “Undefined array key 0”）等问题。
laravel 的 `paginate()` 方法内部已自动处理 limit 和 offset，若手动调用 `limit()` 会导致分页逻辑错乱，引发页数虚高、空数组报错（如 “undefined array key 0”）等问题。
在 Laravel 中，paginate() 是一个封装完善的分页方法——它不仅自动计算总记录数（通过 COUNT(*) 查询），还会根据当前页码动态生成 LIMIT 和 OFFSET，并返回包含数据、分页器元信息（如 last_page、current_page、hasPages() 等）的 LengthAwarePaginator 实例。
你遇到的问题根源非常明确：
$dataGlobal = DB::table('articles')
->orderBy('articleDate', 'desc')
->orderBy('articleHour', 'desc')
->orderBy('articleMinute', 'asc')
->orderBy('articleSeconde', 'asc')
->limit(150) // ❌ 错误：手动 limit 干扰 paginate 内部逻辑
->paginate(15); // → 导致总记录数统计失真，生成多余空页（如第5–23页无数据）->limit(150) 强制截断原始查询结果，但 paginate(15) 仍会基于*未加 limit 的全量 COUNT()**（或错误缓存的计数）推算总页数，造成「声称有23页」却实际只有前几页有数据，后续页访问 $dataGlobal->items() 时因集合为空而触发 Undefined array key 0 错误（常见于 Blade 中直接索引 {{ $articles[0]->title }}）。
✅ 正确写法是移除 limit()，完全交由 paginate() 控制分页数量：
$dataGlobal = DB::table('articles')
->orderBy('articleDate', 'desc')
->orderBy('articleHour', 'desc')
->orderBy('articleMinute', 'asc')
->orderBy('articleSeconde', 'asc')
->paginate(15); // ✅ 正确：每页15条，自动计算总页数与偏移? 补充说明：若你确实需要「仅查询最多150条记录参与分页」（例如性能敏感场景），应改用
forPage()+ 手动分页，或先取 ID 列表再分页，但绝大多数情况无需此操作——paginate()的 COUNT 查询本身高效，且数据库索引可保障性能。
在 Blade 模板中安全使用分页数据，推荐始终检查数据存在性：
{{-- 安全遍历 --}}
@foreach($dataGlobal as $article)
<h3>{{ $article->title }}</h3>
@endforeach
{{-- 安全访问首条（避免 Undefined array key 0） --}}
@if($dataGlobal->isNotEmpty())
<p>最新文章：{{ $dataGlobal->first()->title }}</p>
@endif
{{-- 渲染 Bootstrap 5 分页 --}}
{{ $dataGlobal->onEachSide(2)->links('pagination::bootstrap-5') }}⚠️ 注意事项：
- 该问题仅出现在首页，很可能因为首页查询加了
limit(150)，而其他页面未加，印证了根本原因； - 不要修改
vendor下的分页视图来“修复”显示问题——需从查询逻辑源头修正； - 若使用
simplePaginate()，则不执行 COUNT 查询，但也不支持跳转末页，适用于大数据集的简单翻页。
总结：paginate() 是自洽的分页解决方案，混用 limit() 会破坏其契约。删掉多余的 ->limit()，即可彻底解决页数虚高与数组越界报错。
