凭证生命周期失控源于异常路径绕过正常销毁流程，导致凭证对象未析构、重复创建或注册，进而引发内存泄漏与监控失真。
这不是“多次调用 release()”本身导致凭证溢出，而是异常处理逻辑与资源管理机制错配引发的**凭证生命周期失控**——本质是凭证对象未被正确销毁，却在异常路径中反复创建或重复注册。
凭证对象未析构，异常路径绕过正常释放流程
很多凭证管理模块（如 OAuth token manager、API key pool）依赖 RAII 或引用计数机制自动清理。但若在 catch 块中仅做日志或重试，却未显式调用 destroy()、invalidate() 或未让凭证对象离开作用域，该凭证实例就会持续驻留内存。更危险的是：当异常反复触发（如高频接口失败），每次都会 new 一个新凭证，而旧凭证因未析构不断累积。
错误地在异常分支中重建凭证
常见反模式是在 catch 块里直接 new 凭证或调用 init()：
- 例如：捕获 token 过期异常后，不复用原有凭证管理器，而是 new TokenRefresher().refresh() —— 每次都生成全新凭证对象
- 又如：在重试循环中，每次迭代都调用 credentials.loadFromConfig()，但未释放前一次加载的 credential 实例
凭证注册中心未去重或未失效标记
部分系统将凭证写入全局 registry（如 ConcurrentHashMap
- 同一业务 ID 多次注册不同 token 实例
- 过期凭证未标记为 invalid，仍被计入活跃凭证统计
- 监控指标（如 “active_credentials”）持续累加，最终触发阈值告警甚至服务限流
混淆 release() 语义：它不等于销毁
某些 SDK 的 release() 方法仅表示“归还到连接池”或“标记为可复用”，而非真正释放。若凭证本身是 long-lived（如 client certificate + private key），调用 release() 只是回收句柄，底层资源仍在。异常频繁触发时，大量“已 release 但未 close”的凭证堆积，等效于泄漏。
