partialresultexception是ldap搜索因服务端限制（如ad默认1000条大小限制、超时或未启用分页控件）而返回部分结果的协议级信号，应作为分页提示而非错误处理，需配合pagedresultscontrol与cookie循环获取全部结果。
partialresultexception 是 java 中使用 jndi（java naming and directory interface）访问 ldap 目录服务时常见的运行时异常，表示在执行搜索操作过程中，服务器返回了部分结果后中断（例如因超时、配额限制、分页限制或网络中断），未能返回全部匹配条目。
为什么会触发 PartialResultException？
LDAP 服务器（如 OpenLDAP、Active Directory）为防止资源耗尽，常对搜索操作施加隐式限制：
- AD 默认单次搜索最多返回 1000 条结果（“大小限制”），超出即截断并抛出该异常；
- 服务器配置了搜索超时（如 120 秒），查询未完成即中止；
- 客户端未启用分页控件（Paged Results Control），无法分批次拉取大数据集；
- 网络不稳定或服务器负载高，导致连接提前关闭。
如何安全地实现多目录检索并获取全部结果？
关键不是忽略异常，而是主动适配 LDAP 的分页与容错机制：
- 启用 Paged Results 控件：在 DirContext.search() 前设置 com.sun.jndi.ldap.LdapContext.CONTROL_FACTORIES 和分页请求（如 new PagedResultsControl(1000, Control.NONCRITICAL)）；
- 循环获取下一页：每次收到 PartialResultException 后，检查响应中的 cookie，用新 cookie 发起下一页请求，直到 cookie 为空；
- 捕获并处理 PartialResultException：它本身不是错误，而是协议级提示，需在 catch 块中继续分页逻辑，而非直接抛出；
- 避免盲目增大 sizeLimit：AD 不允许客户端绕过 1000 条限制（除非服务端显式提升 maxPageSize），强行设大值无效且易触发拒绝服务。
常见误操作与建议
很多开发者误以为这是网络错误而重试整个搜索，反而加剧服务器压力：
- ❌ 在 catch(PartialResultException) 中直接 retry 搜索同一 baseDN + filter —— 大概率重复失败；
- ❌ 忽略异常、只取已返回的前 N 条——业务数据不完整；
- ✅ 正确做法是结合分页控件 + cookie 状态机管理，把一次“全量搜索”拆解为多次受控的“页面请求”；
- ✅ 对跨多个 baseDN 的多目录检索，应为每个目录单独建立上下文并分页处理，避免混用连接和 cookie。
不复杂但容易忽略。核心就一条：把 PartialResultException 当作分页信号，而不是故障信号。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
