合并后分页应优先用数据库UNION+LIMIT/OFFSET，而非PHP的array_merge+array_slice；后者仅适用于≤2000条且无复杂排序的静态小数据，否则会导致内存暴增、丢失索引优化、排序失真及总页数错误。
合并后的结果分页，本质是“先合并、再分页”，但直接在 PHP 里用 array_merge() 或循环拼数组再切片（array_slice()），只适用于小数据量；一旦合并后总数超几千条，内存和性能会明显恶化——这不是分页逻辑错了，而是分页对象错了。
为什么不能直接对合并数组用 array_slice() 分页
常见错误是：从多个来源（比如不同表、API、缓存键）取数据，array_merge($a, $b, $c) 后统一算 $offset 和 $limit，再 array_slice($merged, $offset, $limit)。问题在于：
- 所有数据必须一次性加载进内存，哪怕最终只显示 10 条，也可能拉取上万条原始数据
- 无法利用数据库索引或游标优化，排序（如
ORDER BY created_at DESC）需在 PHP 层重排，丢失原有序列稳定性 - 总页数计算失真：合并前各源数据可能有重叠、去重未做，
count($merged)不等于真实逻辑总数 - 翻页时无法复用已查过的中间结果，每次请求都得重新合并+切片
array_slice() 分页仅适用于明确可控的小规模合并
如果你确认合并后总数稳定 ≤ 2000 条（例如配置项列表、本地静态数据聚合），且无需复杂排序或筛选，可用 array_slice()，但必须前置校验：
- 用
(int)强转$_GET['page']，并限制最小为 1：$page = max(1, (int)($_GET['page'] ?? 1)); - 固定每页条数（如
$per_page = 15），避免传参控制导致越界 - 合并前去重（如用
array_unique($merged, SORT_REGULAR)），否则count()和array_slice()行为不可预期 - 排序必须在合并后、切片前完成，且用稳定算法：
usort($merged, fn($a, $b) => $b['time'] $a['time']);
示例片段：
立即学习“PHP免费学习笔记（深入）”；
$data_a = get_from_db('news', ['limit' => 50]);
$data_b = get_from_api('announcements');
$merged = array_unique(array_merge($data_a, $data_b), SORT_REGULAR);
usort($merged, fn($x, $y) => $y['created_at'] <=> $x['created_at']);
$total = count($merged);
$per_page = 15;
$page = max(1, (int)($_GET['page'] ?? 1));
$offset = ($page - 1) * $per_page;
$items = array_slice($merged, $offset, $per_page);
真正可扩展的方案：用数据库 UNION + LIMIT/OFFSET
当合并源来自同库多表（如 posts、pages、products），优先走 SQL UNION ALL，让数据库完成合并、排序、截断——这是唯一能兼顾正确性、性能和总页数计算的路径。
- 所有子查询字段数、类型、顺序必须严格一致，否则
UNION报错 - 用
UNION ALL而非UNION，避免隐式去重开销（除非业务真需要） -
ORDER BY必须放在整个UNION语句末尾，不能在子查询里写 - 总记录数必须单独查一次
SELECT COUNT(*) FROM (…UNION ALL…) AS t，不能依赖子查询各自COUNT相加 - 偏移量大时（如
OFFSET 10000），仍会慢；此时应改用基于主键/时间戳的游标分页（WHERE id > ? ORDER BY id LIMIT 10）
典型结构：
(SELECT id, title, 'post' AS type, created_at FROM posts) UNION ALL (SELECT id, name AS title, 'product' AS type, updated_at AS created_at FROM products) ORDER BY created_at DESC LIMIT :limit OFFSET :offset
分页链接必须保留所有筛选参数，否则查询条件丢失
合并分页常伴随搜索（如关键词跨表查），但点击第 2 页链接时，$_GET['q'] 很容易丢——因为生成页码 HTML 时没带参数。正确做法是用 http_build_query() 动态拼 URL：
- 提取当前全部有效参数：
$params = $_GET; unset($params['page']); - 生成链接时：
<a href="?page=2&'.http_build_query($params).'">2</a> - 如果参数含数组（如
tags[]=a&tags[]=b），http_build_query()原生支持，不用手动处理 - 避免硬编码参数名，否则新增筛选字段就得改所有分页生成逻辑
最容易被忽略的是：合并分页的「总页数」必须基于实际合并后的总数计算，而不是按单个数据源估算。哪怕你合并了 3 个表，每个表都有 1000 条，真实合并去重后可能只剩 1200 条——页码栏显示 “共 300 页” 就是严重误导。
