PeerBanHelper 配置重载导致封禁名单丢失问题分析

问题现象

在 PeerBanHelper 7.4.3 版本中，用户报告了一个关键性问题：当修改并保存 PBH 配置后，系统会丢失最近的进度作弊封禁名单，但这些记录仍能在封禁历史中查询到。具体表现为：

1. 用户拦截了一个进度反作弊 IP
2. 十分钟后修改 PBH 配置并保存
3. 配置重载后最近的封禁名单丢失
4. 封禁历史记录中仍能查到相关记录

技术分析

根本原因

该问题的核心在于 PeerBanHelper 的配置重载机制设计。当用户修改配置并保存时，系统会执行以下流程：

1. 加载新配置
2. 重新初始化各模块
3. 从保存的封禁列表缓存文件中恢复封禁项

问题出在第三步的恢复机制上。系统虽然会从缓存文件中恢复封禁项，但这个过程可能无法完全捕获最近添加的封禁记录，特别是那些尚未被持久化到长期存储中的临时记录。

日志分析

从用户提供的日志可以看出：

1. 系统在 22:29:29 成功封禁了一个 BitComet 客户端
2. 22:40:45 执行了解封操作
3. 22:43:32 用户修改配置触发重载
4. 重载后系统报告"从保存的封禁列表缓存文件中恢复了 63 个封禁项"
5. 但最近的封禁记录已不在当前封禁名单中

解决方案

项目维护者采用了折中的解决方案：

不再在配置重载时重新加载封禁列表。这一改变直接解决了问题的源头，确保配置变更不会影响当前的封禁状态。

技术启示

1. 状态持久化策略：对于实时安全系统，状态管理需要更精细的持久化策略，确保关键数据不会因配置变更而丢失。

2. 配置与状态分离：系统设计时应将动态运行状态与静态配置明确分离，避免两者之间的不必要耦合。

3. 恢复机制验证：任何从持久化存储恢复状态的机制都需要严格的验证流程，确保数据完整性。

用户建议

对于遇到类似问题的用户：

1. 升级到修复该问题的版本
2. 重要操作前手动导出封禁列表作为备份
3. 监控系统日志，特别是配置变更前后的状态变化

该问题的修复体现了 PeerBanHelper 项目对数据一致性的重视，也为类似工具的状态管理提供了有价值的参考案例。