内存泄漏主因是尾指针未重置，致已释放节点仍被链表逻辑引用；删尾节点或唯一节点时须同步更新ll->tail为del->prev或null，并验证prev/next双向指针及tail->next是否为空，释放前加断言，释放后置空指针，再用遍历计数交叉验证。
排查因未重置尾节点指针引发的链表内存泄漏，关键不是“有没有释放节点”，而是“释放后链表结构是否仍持有对它的隐式引用”。尾指针未更新会导致已释放节点在逻辑上仍被链表“认为存在”，后续遍历可能跳过、重复访问或根本无法到达，最终使部分节点从未被 free。
确认尾指针是否被遗漏更新
检查所有涉及删除操作的函数，尤其是删除尾节点或唯一节点的路径：
- 若当前节点 del == ll->tail，必须执行 ll->tail = del->prev
- 若删除后 del->prev 为 NULL（即原链表只剩一个节点），则 ll->tail 必须置为 NULL，否则 tail 指向已释放内存
- 注意：单向更新 next 指针不等于双向链表已解耦——prev 链和 tail 指针都需同步处理
验证释放前节点是否真正脱离链表结构
释放前加断言或调试日志，确认该节点不再被任何有效指针引用：
- 检查 del->prev->next == del 和 del->next->prev == del 是否成立（若非空）
- 若 del == ll->tail，验证 ll->tail->next == NULL —— 若不成立，说明 tail 仍指向一个 next 不为空的节点，结构已损坏
- 释放后立即将 del->prev = del->next = NULL，再 free，可防止误用残留指针
用遍历+计数交叉验证释放完整性
写一个独立的链表长度统计函数（从 head 开始遍历到 next == NULL），与你预期的节点数量对比：
- 若统计数 > 实际应存节点数，说明有“幽灵节点”——可能是 tail 未更新导致遍历绕回或跳过已删节点
- 若统计数
- 特别关注：删除尾节点后调用该函数，看是否仍能访问到原尾节点地址（悬空访问）或提前终止（next 错误）
借助工具定位未释放节点归属
使用 Valgrind 的 --leak-check=full --show-leak-kinds=all 运行程序，并聚焦报告中的“definitely lost”块：
- 查看泄漏块的分配堆栈，定位是哪次 malloc/new 对应未释放节点
- 若多次删除操作后只漏掉尾部若干节点，高度提示 tail 更新缺失
- 配合 --track-origins=yes 可追踪指针来源，确认是否因 tail 未置空，导致某次遍历从 tail 开始却跳过了真实尾前节点
