不能在 Blade 组件内调用 $data->links()，因其依赖请求上下文与 URL 参数逻辑，硬编码会导致模板路径错误、查询参数冲突、职责不清及复用性丧失；分页导航必须由父级视图显式控制。
直接用 <x-table></x-table> 包裹分页数据行，但不处理分页导航本身——分页逻辑必须交给外部 $users->links() 或自定义分页视图，组件内硬塞 links() 会破坏复用性、导致路径冲突或类名污染。
为什么不能在 Blade 组件里直接调用 $data->links()
Blade 组件接收的是已分页的集合（如 $users），但它本身不持有请求上下文、不控制 URL 参数拼接逻辑。若在组件内部写 {{ $users->links() }}：
- 会强制依赖默认分页视图路径（如
resources/views/vendor/pagination/tailwind.blade.php），一旦项目没发布该模板，直接报错View [pagination::tailwind] not found - 无法统一管理查询参数保留逻辑（比如搜索关键词
appends($search)），组件外层已做appends()，组件内再调一次就重复或冲突 - 组件失去“只管渲染数据行”的职责边界，变成“又管数据又管分页导航”，后续想换成分页插件或游标分页时，得挨个改组件内部
resources/views/components/table.blade.php 应只负责表格结构
一个干净的表格组件，只接收 $rows、$headers、$emptyText 等纯展示参数，分页导航由父级视图决定位置和样式：
- 组件内用
@foreach($rows as $row)渲染<tr>，不碰 <code>currentPage()、lastPage()这类分页元数据 - 空状态用
{{ $emptyText ?? '暂无数据' }}，不调用$rows->isEmpty()—— 因为$rows是LengthAwarePaginator实例，isEmpty()返回的是当前页是否为空，不是总数据是否为空 - 若需显示“共 X 条”，应由父级传入
$total（即$users->total()），组件不主动调用total()—— 避免在 simplePaginate 场景下报错（它没有total()方法）
示例片段：
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
@props(['rows', 'headers', 'emptyText' => '暂无数据', 'total' => null])
<table class="w-full">
<thead>
<tr>
@foreach($headers as $header)
<th class="text-left py-2 px-3">{{ $header }}</th>
@endforeach
</tr>
</thead>
<tbody>
@forelse($rows as $row)
<tr class="border-t">
@foreach($headers as $key => $header)
<td class="py-2 px-3">{{ $row[$key] ?? $row->$key ?? '' }}</td>
@endforeach
</tr>
@empty
<tr><td colspan="{{ count($headers) }}" class="text-center py-4">{{ $emptyText }}</td></tr>
@endforelse
</tbody>
</table>
@if($total !== null)
<p class="text-sm text-gray-500 mt-2">共 {{ $total }} 条</p>
@endif
分页导航必须由父级视图显式控制
真正决定分页怎么渲染、在哪渲染、带哪些参数的，是使用该组件的页面（如 resources/views/users/index.blade.php）：
- 用
$users->links('pagination.custom')指向你发布的自定义分页模板，而不是依赖组件内部硬编码 - 若需保留搜索参数，统一在外层调用
appends(request()->except('page'))，不要让组件去猜该 append 什么 - 动态分页场景（如 tab 切换不同数据源），用
withPath()显式指定基础路径，避免链接跳转到错误路由 - 简单列表页可直接放组件下方：
{{ $users->links('pagination.custom') }}；后台管理页可能需要分页导航在表格上方+下方两处，那就手动写两次
复杂表格组件建议拆成两个独立组件
当表格既要支持排序、筛选、导出，又要集成分页导航时，强行塞进一个 <x-table></x-table> 会导致维护成本飙升：
-
<x-table-body :rows="$users"></x-table-body>：只负责渲染<tr> 行，接收 <code>$rows和列定义 -
<x-table-pagination :paginator="$users"></x-table-pagination>：只负责渲染分页导航，接收完整分页器实例，内部调用links()并处理appends/withPath - 两者通过相同 props 命名约定协作（如都接受
:paginator），但职责彻底分离，未来替换分页方案时只需重写后者
这种拆分不是过度设计——Laravel 自身的 LengthAwarePaginator 和 Paginator 类也是按“有总数”和“无总数”拆开的，组件设计同理。
最易被忽略的一点：分页组件的 links() 调用，本质是生成 HTML 字符串，它不参与 Laravel 的组件生命周期（比如 mount、update），也不受 $attributes 合并影响。所以别指望给 <x-table-pagination></x-table-pagination> 传个 class="my-paginate" 就能自动加到外层 <div> 上——它输出的是完整 <code><ul class="pagination"></ul>，样式覆盖得靠 CSS 选择器，不是靠 Blade 属性透传。
