PHP 7.4起ldap_control_paged_result_response()被弃用，须改用ldap_control_paged_result()→ldap_search()→ldap_parse_result()手动解析分页控制项，依赖cookie逐页获取，不可跳页或预估总数。
PHP 7.4 中 ldap_control_paged_result_response() 已被弃用，不能用
这个函数在 PHP 7.4.0 就标为 deprecated，到 PHP 8.0.0 直接移除。如果你在 PHP 7.4 环境下看到它返回 false 或静默失败，不是配置或网络问题，而是它本就不该再调用。继续用会埋下升级隐患，且无法获得服务端真实分页状态（比如 $cookie 和 $estimated）。
必须改用标准的 LDAP 控制扩展流程：ldap_control_paged_result() 发起请求 → ldap_search() 执行 → ldap_parse_result() + 手动提取响应控制项。
服务端截断（如只返回 1000 条）本质是未启用分页或 cookie 未传递
LDAP 服务器（如 OpenLDAP、Active Directory）默认限制单次查询结果数（sizeLimit），常见值为 1000。这不是 PHP 截断，是服务端策略。若没正确发送分页控制，服务端就按默认上限硬截断，且不报错。
关键点在于：必须每次调用 ldap_control_paged_result() 并传入上一轮返回的 $cookie，否则服务端视为新查询，重置计数器。
立即学习“PHP免费学习笔记（深入）”；
- 首次调用：
ldap_control_paged_result($link, $pageSize, true, $cookie)，此时$cookie应为空字符串或null - 后续调用：把上一轮
ldap_parse_result()解析出的control['value']['cookie']原样传入 - 务必检查
ldap_parse_result()返回的 controls 数组里是否有1.2.840.113556.1.4.319（pagedResults OID），没有说明服务端根本没返回分页响应
手动解析分页响应要避开几个坑
ldap_parse_result() 不会自动填充 $cookie 和 $estimated，得自己从返回的 controls 里抠。PHP 7.4 的 LDAP 扩展对 control 解析较原始，容易漏字段或类型错乱。
- 不要依赖
ldap_get_entries()后直接读$result—— 它不包含控制信息 - 必须在
ldap_search()后立即调用ldap_parse_result($link, $result, $errcode, $matcheddn, $errmsg, $referrals, $controls) -
$controls是数组，需遍历找oid === '1.2.840.113556.1.4.319'，然后取$controls[0]['value']['cookie']（注意是嵌套数组，不是字符串） - 如果
$controls[0]['value']['cookie']是空字符串，说明已是最后一页；非空才继续下一轮 -
$estimated字段在 PHP 7.4 中基本不可靠，别用来预估总条数，仅作参考
AD/LDAP 分页和 MySQL 分页逻辑完全不同，不能套用 OFFSET 思维
LDAP 分页是「状态式游标」：服务端内部维护一个查询上下文，靠 cookie 恢复位置。它不接受 WHERE 或 ORDER BY 调整，也不支持跳转任意页（比如直接查第 50 页）。你只能一页一页 fetch，且每页大小必须固定（$pageSize 不能变）。
这意味着：前端不能做「跳转页码」输入框，只能提供「下一页」「上一页」（上一页需缓存历史 cookie）；也不能用 count() 预算总页数 —— 服务端不告诉你总数，$estimated 是估算，常不准。
真正容易被忽略的是：连接必须保持活跃。如果两次分页请求间隔太久（如 AD 默认超时 15 分钟），服务端会丢弃上下文，再传旧 cookie 会返回无效错误。生产环境建议加重试逻辑，并记录每次请求耗时。
