LDAP连接池不能直接用ldap.Dial，因其每次调用新建TCP连接，高并发下易耗尽socket或触发服务器连接拒绝；必须使用ldap.NewConnPool手动管理，需合理配置池大小、IdleTimeout、MaxIdleConnsPerHost，并预热连接。
LDAP连接池为什么不能直接用ldap.Dial？
因为ldap.Dial每次调用都新建TCP连接，企业级场景下并发认证请求一上来就可能耗尽socket或触发LDAP服务器连接拒绝。必须用连接池——但Go标准库不提供，得靠gopkg.in/ldap.v3的ldap.NewConnPool手动管理。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 池大小按预期峰值QPS × 平均绑定耗时（秒）估算，比如100 QPS × 0.2s ≈ 20，再加20%余量设为24
- 务必设置
IdleTimeout（建议30s）和MaxIdleConnsPerHost（建议≤5），否则空闲连接长期占着LDAP服务器资源 - 初始化后调用
pool.Connect()预热，避免首请求延迟突增
用户DN怎么动态拼接才安全？
硬编码uid={username},ou=users,dc=example,dc=com是典型漏洞点：一旦username含逗号、反斜杠或空格，DN解析失败或被注入恶意OU路径。LDAP协议要求DN中特殊字符必须转义。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别自己写转义逻辑，用
ldap.EscapeFilter处理用户名（注意：它针对filter，但DN里CN/UID字段规则一致） - 更稳妥的做法是先用
Search查出用户真实DN：baseDN="ou=users,dc=example,dc=com"+filter="(uid="+ldap.EscapeFilter(username)+")" - 搜索返回的
Entry.DN才是可直接用于Bind的合法DN，绕过所有拼接风险
为什么Bind成功后还要Search校验属性？
LDAP的Bind只验证凭据，不保证账号启用、未过期、属目标OU——这些全靠业务属性控制。跳过这步，攻击者可能用已禁用账号的旧密码通过认证。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在
Bind成功后立即执行一次Search，检查userAccountControl（Windows AD）或accountStatus（OpenLDAP）等字段 - 避免在
Bind时传入完整DN做身份断言——这会让LDAP服务器跳过组策略/ACL检查 - Search范围用
ScopeBase而非ScopeSingleLevel，减少网络往返和服务器负载
Go的context.Context在哪几个关键点必须传入？
LDAP操作天然阻塞，没上下文超时会导致goroutine堆积、HTTP handler卡死、连接池饿死。但很多人只在最外层加context.WithTimeout，漏掉底层调用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
pool.Search、conn.Bind、conn.Close三个地方必须显式传入带timeout的ctx - 不要复用HTTP handler的
req.Context()直接传给LDAP——它的cancel可能由客户端断连触发，而LDAP需要独立的后端超时（比如3s） - 连接池
Close前调用pool.WaitIdle()并设10s等待，否则强行关闭可能中断正在跑的Search
