新人入群验证系统是一个基于图片验证码的群聊安全管理插件。当新成员加入群聊时，系统会自动发送图片验证码，要求新成员在指定时间内完成验证，防止恶意机器人和垃圾账号入群。
版本: 3.0
作者: p1930n 测试框架: Astrbot 服务端: Napcat
- 新成员入群时自动触发验证流程
- 同时向群聊和私聊发送图片验证码
- 支持群聊和私聊双通道验证
- 验证成功后自动撤回验证相关消息，保持群聊整洁
- 高可识别字符集（排除易混淆字符如 O.0.Q, I.1, Z.2 等）
- 多层干扰机制：噪声纹理、波浪扭曲、高斯模糊、RGB通道偏移
- 可自定义图片尺寸、字体大小、干扰参数
- 支持字符旋转和随机偏移
- 基于三层SHA256加密生成唯一放行码
- 放行码格式：
0x+ 22位十六进制字符 - 群主和管理员可直接发送放行码批准新成员
- 放行码具有时效性，验证完成后自动失效，同时删除服务器端的放行码储存
- 支持验证码刷新功能（可配置刷新次数）
- 多次错误后的渐进式处理（踢出或禁言）
- 超时自动处理（禁言或踢出）
- 定时提醒待验证用户
- 全局配置和群级配置双层体系
- 支持两种处理模式：立即踢出模式和禁言模式
- 可自定义验证时限、错误次数、刷新次数等参数
- 实时生效，无需重启
- 支持并发/顺序两种撤回模式，可动态切换
- 智能分批处理，避免API瞬间压力过大
- 并发模式下撤回速度提升5-10倍
- 自动失败重试机制，确保消息清理完整性
- 可配置批次大小，灵活适应不同环境
新成员入群
↓
生成验证码和放行码
↓
发送验证消息（群聊+私聊）
↓
等待用户响应
├─ 用户输入正确验证码 → 验证成功 → 撤回验证消息 → 欢迎入群
├─ 管理员发送放行码 → 直接放行 → 撤回验证消息 → 欢迎入群
├─ 用户输入错误 → 增加错误计数 → 发送新验证码或踢出.禁言
├─ 用户发送"刷新" → 生成新验证码（有次数限制）
└─ 验证超时 → 踢出或禁言 → 撤回验证消息
放行码基于用户特征确定性生成，确保安全性和唯一性：
- 输入构造:
用户QQ号,群号,时间戳(YYYYMMDDHHMMSS) - 三层SHA256加密:
- 第一层：SHA256(输入消息)
- 第二层：SHA256(第一层结果)
- 第三层：SHA256(第二层结果)
- 格式化处理:
- 转换为十六进制字符串（64字符）
- 截取前22位
- 首位字母强制大写，后续字母确定性混合大小写
- 添加前缀:
0x+ 处理后的22位字符
安全特性:
- 单向不可逆：无法从放行码反推用户信息
- 确定性生成：同一用户在同一时刻生成的放行码相同
- 大小写敏感：增加破解难度
- 无法伪造：需要准确的用户信息和时间戳
配置项：kick_after_errors（设置为非None值）
- 允许用户错误指定次数
- 达到错误次数立即踢出群聊
- 验证超时也会踢出
- 适用于严格管理的群组
示例：
kick_after_errors = 0：不允许错误，首次错误立即踢出kick_after_errors = 3：允许错误3次，第3次错误时踢出
配置项：kick_after_errors = None（或设置为-1）
- 使用
max_errors作为最大错误次数 - 超过错误次数后长期禁言
- 验证超时也会禁言
- 适用于宽松管理的群组
所有管理员命令需要 OP 或 WL 权限。
查看插件帮助信息。系统会将完整帮助文档发送到私聊。
使用场景: 初次使用插件时查看功能说明
在当前群启用新人验证功能。配置会永久保存。
使用场景: 群组需要开启验证功能时
在当前群禁用新人验证功能。配置会永久保存。
使用场景: 临时关闭验证或不再需要验证时
查看当前群的待验证用户列表。
显示信息:
- 用户昵称和QQ号
- 当前错误次数.最大允许错误次数
- 已使用的刷新次数
- 剩余验证时间
使用场景: 了解当前有哪些用户正在验证中
人工批准指定用户通过验证，跳过验证码输入环节。
参数:
[QQ号]: 待批准用户的QQ号
执行效果:
- 从验证列表移除该用户
- 发送批准成功消息到群聊
- 撤回所有验证相关消息
- 发送私聊通知
使用场景:
- 确认是真实用户但无法完成验证
- 特殊情况需要直接放行
查看当前群的长期禁言用户列表。
显示信息:
- 用户昵称和QQ号
- 禁言时间
- 禁言原因
使用场景: 了解因验证失败被禁言的用户
解除指定用户的禁言状态。
参数:
[QQ号]: 待解除禁言的用户QQ号
执行效果:
- 解除QQ禁言
- 从禁言列表移除
- 保存配置
使用场景:
- 确认误判需要解除禁言
- 用户申诉成功
测试验证功能，使用发送者自己作为测试对象。
执行效果:
- 触发完整验证流程
- 生成验证码并发送到群聊和私聊
- 可用于测试配置是否正常工作
使用场景:
- 修改配置后测试效果
- 排查功能异常
自动化超时测试，完整模拟验证超时场景。
执行流程:
- 随机选择一个普通群成员（或使用发送者）
- 临时修改验证时限为约3.6秒
- 触发验证流程
- 等待超时发生
- 检查超时处理结果
- 自动解除禁言
- 恢复原配置
使用场景: 测试超时处理机制是否正常
执行完整流程模拟测试，覆盖 .verify test 未涉及的复杂场景。
指令格式:
.verify simulate [basic|kick|mute|timeout]
共用特性:
- 使用测试账号列表（通过
/verifyconfig testusers add管理）；列表为空时默认使用指令执行者 - 直接调用主业务逻辑：验证码生成、消息撤回、踢人/禁言、超时处理等全部走真实路径
- 结果以群消息形式反馈，可结合日志与统计命令进一步排查
子场景说明:
basic: 模拟正常验证通过流程，检查消息撤回、通过统计是否正确kick: 临时启用立即踢出模式，连续错误触发踢出与清理mute: 在禁言模式下反复错误，触发禁言链路并验证禁言列表timeout: 将待验证数据标记超时，触发超时处理（踢/禁言与消息清理）
使用场景:
- 发布或升级前的全链路自检
- 验证踢出/禁言/刷屏等复杂流程是否按预期执行
- 快速回归新配置或修复是否生效
生成测试放行码，用于调试放行功能。
执行效果:
- 使用发送者的QQ号和当前时间生成放行码
- 显示详细的生成过程和参数
- 放行码单独成行，方便复制
显示信息:
- 模拟入群信息（昵称、QQ号、群号、时间）
- 加密输入格式
- 生成的放行码
- 算法说明
- 测试方法
使用场景:
- 测试放行码生成算法
- 向管理员演示放行码功能
查看验证系统统计信息。
统计数据:
- 总验证次数
- 验证成功.失败.超时次数
- 总禁言数
- 发送提醒次数
- 成功率
- 运行时间
- 当前待验证用户数
- 当前禁言用户数
- 已启用群组数
使用场景: 了解插件运行效果和数据统计
显示全局配置信息。
显示内容:
- 时间设置（验证时限、提醒间隔、检查间隔）
- 验证设置（最大错误次数、验证码长度、禁言时长）
- 图片设置（尺寸、字体大小）
- 干扰参数（噪声、波浪、模糊等）
- 随机范围参数
- 撤回设置
修改全局配置参数。修改后立即生效，无需重启。
常用参数:
| 参数 | 说明 | 取值范围 | 示例 |
|---|---|---|---|
timeout |
验证时限（小时） | >0，支持小数 | 24 |
reminder |
提醒间隔（小时） | >0，支持小数 | 4 |
errors |
最大错误次数 | ≥1 | 5 |
length |
验证码长度 | ≥1 | 6 |
width |
图片宽度（像素） | ≥1 | 400 |
height |
图片高度（像素） | ≥1 | 200 |
fontsize |
字体大小（pt） | ≥1 | 80 |
recall_min |
最小撤回间隔（秒） | >0 | 1.0 |
recall_max |
最大撤回间隔（秒） | >0 | 2.0 |
高性能干扰参数:
| 参数 | 说明 | 取值范围 | 示例 |
|---|---|---|---|
use_noise_texture |
启用噪声纹理 | true.false | true |
noise_intensity |
噪声强度 | 0.0-1.0 | 0.15 |
use_wave_distort |
启用波浪扭曲 | true.false | true |
wave_amplitude |
波浪振幅（像素） | 0-50 | 8 |
wave_frequency |
波浪频率 | 0.001-0.2 | 0.03 |
use_blur |
启用高斯模糊 | true.false | true |
blur_radius |
模糊半径 | 0.1-5.0 | 1.2 |
use_gradient_bg |
使用渐变背景 | true.false | true |
rgb_shift |
RGB通道偏移（像素） | 0-10 | 2 |
使用示例:
.verifyconfig set timeout 24
.verifyconfig set length 6
.verifyconfig set use_blur true
显示当前群的群级配置。群级配置优先于全局配置。
显示内容:
- 验证时限（显示是否使用全局配置）
- 最大错误次数（显示是否使用全局配置）
- 立即踢出阈值
- 无关内容字数限制
- 是否踢出发无关内容用户
- 允许刷新次数
修改当前群的群级配置。
群级参数:
| 参数 | 说明 | 取值范围 | 示例 |
|---|---|---|---|
timeout |
群级验证时限（小时） | 0.1-168.0 | 12 |
max_errors |
群级最大错误次数 | 1-10 | 3 |
kick_after_errors |
立即踢出阈值 | 0-10 或 -1（禁用） | 3 |
max_length |
无关内容字数限制 | 5-100 | 30 |
kick_irrelevant |
踢出发无关内容用户 | true.false | true |
regenerate_count |
允许刷新次数 | 0-10 | 3 |
立即踢出模式说明:
kick_after_errors = 0: 不允许错误，首次错误即踢出kick_after_errors = 1: 允许错误1次，第1次错误时踢出kick_after_errors = 3: 允许错误3次，第3次错误时踢出kick_after_errors = -1: 禁用立即踢出，使用禁言模式
使用示例:
.verifyconfig group set timeout 6
.verifyconfig group set kick_after_errors 0
.verifyconfig group set regenerate_count 5
重置当前群的群级配置，恢复使用全局配置。
运行系统诊断，检查插件运行状态。
检查项目:
- Pillow库安装状态
- 字体文件是否存在
- 配置文件状态
- 数据文件状态
- 配置完整性
- 运行状态
- 统计数据
使用场景:
- 插件异常时排查问题
- 检查系统依赖
测试字体效果，生成测试验证码预览。
执行效果:
- 生成一个测试验证码
- 显示当前字体配置
- 将验证码图片发送到私聊
使用场景:
- 检查字体是否正常加载
- 预览验证码效果
新成员在群聊或私聊中直接发送验证码完成验证。
输入要求:
- 不区分大小写
- 必须完整输入验证码
- 允许的错误次数由配置决定
新成员在群聊中发送以下任一关键词可刷新验证码：
刷新refresh重新生成shuaxin
限制:
- 刷新次数由群级配置决定（默认3次）
- 用完后无法再刷新
- 刷新会生成新的验证码图片
群主或管理员直接在群聊中发送放行码即可批准对应用户。
放行码格式: 0x 开头 + 22位十六进制字符
特点:
- 大小写敏感，必须精确匹配
- 每个用户的放行码唯一
- 仅在验证期间有效
- 放行后自动撤回验证消息
.verify enable
.verifyconfig group set timeout 2
.verifyconfig group set kick_after_errors 0
.verifyconfig group set kick_irrelevant true
.verifyconfig group set regenerate_count 1
效果: 2小时内必须验证，不允许错误，发送无关内容直接踢出，只能刷新1次。
.verify enable
.verifyconfig group set timeout 24
.verifyconfig group set kick_after_errors -1
.verifyconfig group set max_errors 5
.verifyconfig group set kick_irrelevant false
.verifyconfig group set regenerate_count 5
效果: 24小时验证时限，允许错误5次后禁言，发送无关内容仅撤回消息，可刷新5次。
高难度:
.verifyconfig set length 6
.verifyconfig set use_wave_distort true
.verifyconfig set wave_amplitude 15
.verifyconfig set noise_intensity 0.25
.verifyconfig set use_blur true
低难度:
.verifyconfig set length 4
.verifyconfig set use_wave_distort false
.verifyconfig set noise_intensity 0.1
.verifyconfig set use_blur false
新增的并发撤回功能可显著提升消息撤回速度，解决了用户反馈的"发送新验证码后，撤回旧消息需要等待1-2秒"的问题。该功能通过并行执行多个撤回操作，将原本需要逐条处理的消息同时批量撤回，大幅提升响应速度。
核心优势:
- 速度提升: 并发模式下撤回3条消息仅需0.25秒，顺序模式需0.9秒
- 智能分批: 支持设置批次大小，避免瞬间大量API请求
- 动态切换: 可随时在并发/顺序模式间切换，无需重启
- 失败重试: 自动重试失败的撤回操作，确保消息清理完整
- 灵活配置: 适应不同的API稳定性和性能需求
参数名: use_concurrent_recall
类型: Boolean (true/false)
默认值: false (顺序撤回；更安全)
说明: 控制是否启用并发撤回功能；默认关闭以规避 QQ 风控
配置方法:
# 启用并发模式（需评估风险）
.verifyconfig set use_concurrent_recall true
# 使用顺序模式（默认，推荐更安全）
.verifyconfig set use_concurrent_recall false
效果对比:
- 启用 (true): 多条消息并发撤回，速度更快，但可能触发风控
- 禁用 (false): 逐条顺序撤回，牺牲速度换更高成功率（默认）
参数名: concurrent_recall_batch_size
类型: Integer
默认值: 2
取值范围: 1-50
说明: 控制单次并发撤回的最大消息数量；默认 2 条/批，以适配 QQ 风控
配置方法:
# 安全策略（默认 2 条/批次）
.verifyconfig set concurrent_recall_batch_size 2
# 稍快策略（5 条/批次）
.verifyconfig set concurrent_recall_batch_size 5
# 激进策略（≥10 条/批次，需谨慎）
.verifyconfig set concurrent_recall_batch_size 10
批次大小建议:
| 批次大小 | 策略类型 | 适用场景 | 说明 |
|---|---|---|---|
| 2 | 默认安全 | QQ 风控严格环境 | 触发率最低，优先使用 |
| 3-5 | 稍快模式 | 需要略快撤回 | 速度与风控折中 |
| 6-10 | 进阶模式 | 网络稳定、已验证安全 | 需监控风控情况 |
| >10 | 激进模式 | API 非常稳定环境 | 高风险，需谨慎评估 |
查看当前配置:
.verifyconfig show
会在"性能优化"部分显示：
性能优化:
• 并发撤回模式: 禁用(顺序，安全)
• 并发撤回批次大小: 2 条/批次
时间计算公式:
撤回N条消息耗时 ≈ 单次API调用时间 + 一次延迟(0.1-0.3秒)
实际性能:
- 撤回 1 条消息: ~0.2秒
- 撤回 3 条消息: ~0.25秒 (并发执行，几乎同时完成)
- 撤回 5 条消息: ~0.3秒 (并发执行)
- 撤回 10 条消息: ~0.35秒 (单批次并发)
- 撤回 15 条消息: ~0.5秒 (批次大小10时分2批)
优势:
- 速度快，用户体验好
- 大幅减少消息滞留时间
- 群聊清理更及时
时间计算公式:
撤回N条消息耗时 = N × (单次API + 延迟) ≈ N × 0.3秒
实际性能:
- 撤回 1 条消息: ~0.3秒
- 撤回 3 条消息: ~0.9秒 (逐条执行)
- 撤回 5 条消息: ~1.5秒 (逐条执行)
- 撤回 10 条消息: ~3.0秒 (逐条执行)
- 撤回 15 条消息: ~4.5秒 (逐条执行)
优势:
- 每条消息都有独立的重试机会
- 更容易追踪失败原因
- 降低API并发压力
| 消息数量 | 并发模式耗时 | 顺序模式耗时 | 速度提升 |
|---|---|---|---|
| 1 条 | 0.2秒 | 0.3秒 | 1.5倍 |
| 3 条 | 0.25秒 | 0.9秒 | 3.6倍 |
| 5 条 | 0.3秒 | 1.5秒 | 5倍 |
| 10 条 | 0.35秒 | 3.0秒 | 8.6倍 |
| 20 条 | 0.6秒 | 6.0秒 | 10倍 |
适用场景:
- 正常运行环境
- 追求响应速度和用户体验
- API稳定性良好
- 需要快速清理验证消息
优点:
- 撤回速度快，用户体验好
- 大幅减少消息滞留时间
- 群聊清理更及时
- 支持分批处理，避免瞬间大量并发
批次大小选择建议:
- 保守 (5-10条): API偶尔不稳定，追求稳定性
- 推荐 (10-15条): 一般情况下使用，平衡性能和稳定性
- 激进 (15-30条): API非常稳定，追求极致速度
适用场景:
- 遇到撤回异常或失败率高
- API不稳定或经常超时
- 网络环境不佳
- 需要更保守的处理策略
优点:
- 每条消息都有独立的重试机会
- 更容易追踪具体哪条消息失败
- 降低API并发压力
- 出错时更容易定位问题
何时切换到顺序模式:
- 日志中出现大量撤回失败
- API频繁返回限流错误
- 网络经常超时断连
- 需要详细的错误追踪
配置: batch_size=10
待撤回: 3条消息
执行流程:
1. 3条消息同时并发撤回
2. 等待一次延迟 (0.1-0.3秒)
3. 完成
总耗时: ~0.2秒
日志输出:
[NewbieVerification] 批量撤回（并发模式）：开始撤回 3 条消息，批次大小=10
[NewbieVerification] 成功撤回消息ID: 123456
[NewbieVerification] 成功撤回消息ID: 123457
[NewbieVerification] 成功撤回消息ID: 123458
[NewbieVerification] 并发撤回完成: 成功 3/3 条
配置: batch_size=10
待撤回: 15条消息
执行流程:
1. 第1批：10条消息并发撤回
2. 批次间延迟 (0.1-0.3秒)
3. 第2批：5条消息并发撤回
4. 最终延迟 (0.1-0.3秒)
5. 完成
总耗时: ~0.5秒
日志输出:
[NewbieVerification] 批量撤回（并发模式）：开始撤回 15 条消息，批次大小=10
[NewbieVerification] 处理批次 1/2，本批 10 条消息
[NewbieVerification] 处理批次 2/2，本批 5 条消息
[NewbieVerification] 并发撤回完成: 成功 15/15 条
配置: batch_size=15
待撤回: 35条消息
执行流程:
1. 第1批：15条消息并发撤回
2. 批次间延迟 (0.1-0.3秒)
3. 第2批：15条消息并发撤回
4. 批次间延迟 (0.1-0.3秒)
5. 第3批：5条消息并发撤回
6. 最终延迟 (0.1-0.3秒)
7. 完成
总耗时: ~0.7秒
日志输出:
[NewbieVerification] 批量撤回（并发模式）：开始撤回 35 条消息，批次大小=15
[NewbieVerification] 处理批次 1/3，本批 15 条消息
[NewbieVerification] 处理批次 2/3，本批 15 条消息
[NewbieVerification] 处理批次 3/3，本批 5 条消息
[NewbieVerification] 并发撤回完成: 成功 35/35 条
配置: use_concurrent_recall=false
待撤回: 5条消息
执行流程:
1. 撤回消息1 → 延迟0.3秒
2. 撤回消息2 → 延迟0.3秒
3. 撤回消息3 → 延迟0.3秒
4. 撤回消息4 → 延迟0.3秒
5. 撤回消息5 → 延迟0.3秒
6. 完成
总耗时: ~1.5秒
日志输出:
[NewbieVerification] 批量撤回（顺序模式）：开始撤回 5 条消息
[NewbieVerification] 成功撤回消息ID: 123456
[NewbieVerification] 成功撤回消息ID: 123457
[NewbieVerification] 成功撤回消息ID: 123458
[NewbieVerification] 成功撤回消息ID: 123459
[NewbieVerification] 成功撤回消息ID: 123460
[NewbieVerification] 顺序撤回完成: 成功 5/5 条
该功能会应用到以下所有场景的消息撤回：
-
验证码错误处理
- 用户输入错误验证码后，撤回旧验证码和错误消息
- 避免验证消息堆积
-
刷新验证码
- 用户请求刷新验证码后，撤回旧验证码消息
- 快速更新验证界面
-
验证超时处理
- 验证超时后，批量撤回所有验证相关消息
- 保持群聊整洁
-
验证成功/失败
- 完成验证后，批量撤回所有验证历史消息
- 快速清理验证痕迹
-
测试命令
- 执行测试命令后的消息清理
- 提升测试体验
问题: 并发模式会在短时间内发起多个撤回请求，可能触发平台API限流
解决方案:
- 降低
concurrent_recall_batch_size值（如改为5） - 切换到顺序模式：
.verifyconfig set use_concurrent_recall false - 增加撤回延迟：
.verifyconfig set recall_min 0.5
判断标准:
- 日志中出现 "rate limit" 或 "限流" 字样
- 撤回成功率低于80%
- 频繁出现撤回失败错误
建议做法:
- 定期查看日志中的撤回成功率
- 观察 "并发撤回完成: 成功 X/Y 条" 的统计
- 如果失败率高，考虑调整配置
正常标准:
- 成功率应在 95% 以上
- 偶尔失败（1-2条）属于正常，会自动重试
异常标准:
- 成功率低于 80%
- 单批次大量失败（如 5/10 条失败）
- 频繁出现重试日志
不稳定网络:
- 建议使用顺序模式或小批次（5条）
- 增加撤回延迟到 0.5-1.0 秒
- 顺序模式的重试机制更可靠
稳定网络:
- 可以使用较大批次（15-20条）
- 缩短撤回延迟到 0.1-0.2 秒
- 充分发挥并发优势
完全兼容现有配置:
- 不影响撤回间隔配置 (
recall_min/recall_max) - 保留自动失败重试机制
- 无需重启，修改后立即生效
- 可随时在两种模式间切换
数据安全:
- 不影响数据持久化
- 撤回失败不会丢失验证状态
- 支持部分成功场景的处理
.verifyconfig set use_concurrent_recall true
.verifyconfig set concurrent_recall_batch_size 10
.verifyconfig set recall_min 0.1
.verifyconfig set recall_max 0.3
特点: 平衡性能和稳定性，适合大多数使用场景
.verifyconfig set use_concurrent_recall true
.verifyconfig set concurrent_recall_batch_size 20
.verifyconfig set recall_min 0.1
.verifyconfig set recall_max 0.2
特点: 追求极致速度，适合API非常稳定的环境
.verifyconfig set use_concurrent_recall true
.verifyconfig set concurrent_recall_batch_size 5
.verifyconfig set recall_min 0.3
.verifyconfig set recall_max 0.5
特点: 小批次并发，适合API偶尔不稳定的环境
.verifyconfig set use_concurrent_recall false
.verifyconfig set recall_min 0.5
.verifyconfig set recall_max 1.0
特点: 禁用并发，逐条撤回，适合频繁遇到撤回失败的情况
插件的所有数据都会自动保存，包括：
- 全局配置参数
- 群级配置参数
- 已启用群组列表
- 待验证用户信息
- 验证码和放行码
- 错误次数和刷新次数
- 消息ID（用于撤回）
- 长期禁言用户列表
- 禁言原因和时间
保存机制:
- 配置修改后立即保存
- 验证状态变化后自动保存
- 每5分钟自动保存一次
- 重启后自动加载
会被撤回的消息:
- 验证码图片消息
- 错误提示消息
- 刷新验证码消息
- 用户发送的验证码消息
- 提醒消息
不会被撤回的消息:
- 验证成功消息
- 管理员放行消息
- 放行码消息
- 私聊消息
- 验证成功后：延迟1-2秒撤回所有验证消息
- 验证失败后：延迟1-2秒撤回错误消息和用户输入
- 发送新验证码时：撤回旧验证码消息
- 验证超时后：撤回所有验证消息
目的: 保持群聊整洁，避免验证消息干扰正常聊天
- 同一用户的验证消息会批量撤回
- 错误处理时会撤回用户输入
- 超时处理时会撤回所有相关消息
- 放行码需要群主.管理员权限
- 配置命令需要OP.WL权限
- 解除禁言需要OP.WL权限
- 验证期间发送无关内容会被处理
- 多次错误会触发踢出或禁言
- 超时未验证会自动处理
原因: 系统未安装字体文件
解决:
# CentOS.RHEL
yum install dejavu-sans-fonts
# Debian.Ubuntu
apt-get install fonts-dejavu原因: 机器人没有撤回消息权限
解决: 给机器人管理员权限或确保机器人账号可以撤回自己的消息
可能原因:
- 放行码大小写错误（必须精确匹配）
- 用户已完成验证或验证已超时
- 发送者不是群主.管理员
原因: 用户未添加机器人好友
解决: 提示用户添加机器人为好友，或仅使用群聊验证
原因: 干扰参数设置过高
解决:
- 启用高性能干扰参数（噪声纹理、波浪扭曲等）
- 降低传统干扰参数（噪点数量、干扰线等）
- 使用诊断命令检查性能
检查:
- 群级配置优先于全局配置
- 使用
.verifyconfig show和.verifyconfig group show确认配置 - 配置修改立即生效，无需重启
原因: 可能未启用并发撤回模式或批次大小设置过小
解决:
# 启用并发撤回
.verifyconfig set use_concurrent_recall true
# 调整批次大小（推荐10-15）
.verifyconfig set concurrent_recall_batch_size 10
原因: 并发批次过大或API不稳定
解决:
# 降低批次大小
.verifyconfig set concurrent_recall_batch_size 5
# 或切换到顺序模式
.verifyconfig set use_concurrent_recall false
# 增加撤回延迟
.verifyconfig set recall_min 0.5
判断标准: 查看日志中的撤回成功率，正常应在95%以上
验证码使用高可识别字符集，排除易混淆字符：
- 字母: A C D E F H J K L M N P R U V W X Y（18个）
- 数字: 3 4 8 9（4个）
- 排除: O.0.Q（圆形）、I.1（细长）、Z.2、S.5、G.6、T.7、B.8
- 验证码: 使用Python标准random模块生成（可选secrets模块增强安全性）
- 放行码: 三层SHA256哈希 + 确定性大小写混合
- 使用numpy加速图片处理
- 噪声纹理采用矩阵运算
- 波浪扭曲使用矢量化算法
- 消息ID规范化处理
- 使用asyncio.Lock保护共享数据
- 验证列表操作线程安全
- 配置保存原子性操作
- 并发执行: 使用asyncio.gather()并发执行多个撤回任务
- 智能分批: 自动将大量消息分批处理，避免API瞬间压力
- 失败重试: 单个消息撤回失败不影响其他消息，支持自动重试
- 性能优化: 并发模式下撤回速度提升5-10倍
- 灵活配置: 支持动态调整批次大小和并发模式
- 重构验证码生成算法，提升性能
- 新增高性能干扰参数
- 新增放行码机制
- 新增并发撤回功能
- 支持并发/顺序两种撤回模式
- 智能分批处理，可配置批次大小
- 撤回速度提升5-10倍
- 自动失败重试机制
- 优化消息撤回逻辑，延迟计算
- 更完善的群级配置系统
- 新增调试和诊断功能
- v2 (2025-10-04): 新增批次大小配置
- 添加
concurrent_recall_batch_size配置项 - 支持分批并发处理
- 更灵活的性能调优选项
- 添加
- v1 (2025-10-04): 初始版本发布
- 新增并发撤回功能
- 统一批量撤回逻辑
- 支持动态切换模式
如遇到问题或需要帮助，请：
- 使用
.verifydiag运行系统诊断 - 查看日志文件排查错误
- 检查配置文件是否正确
- 联系插件作者或社区支持
本插件遵循AstrBot插件开发规范，仅供学习和研究使用。 https://docs.astrbot.app/dev/star/plugin.html