为什么Twitch机器人会漏掉版主的消息

首先确定消息在哪个环节丢失

检查机器人在同一频道中是否能收到普通消息。如果日志中既没有观众也没有版主，问题通常出在授权、聊天连接或频道名称上。如果能看到观众，但版主的发言缺失，就要在角色过滤器、IRC标签或EventSub订阅中查找原因。

不要只看机器人在聊天中的回复，而要看传入事件日志。消息可能已经到达应用，但因前缀、冷却时间、停用词、忽略列表或权限检查而未能触发命令。测试时，让观众和版主发送相同的简短语句，然后发送相同的命令。

检查频道、机器人账号和IRC连接

确认机器人加入的正是所需频道，并且使用的是应当读取聊天的账号。频道改名、更换登录名或在测试环境与生产环境之间切换后，应用可能仍在线，但监听的是另一个聊天。

连接日志中应能看到成功授权、机器人昵称和加入频道的命令。连接中断后，不仅要检查重连尝试，还要确认是否成功重新登录。自动重连而不记录错误，会掩盖过期的令牌、错误的OAuth密码或频道名称错误。

检查OAuth令牌和读取权限

令牌必须属于机器人用来读取聊天的账号。不要将其与主播的令牌混淆：频道所有者的权限不会转移给单独的机器人账号。通过IRC读取消息需要chat:read权限范围。

如果通过EventSub接收消息，聊天事件需要具有user:read:chat权限的用户令牌。根据授权方案以及由谁创建订阅，还可能需要机器人访问频道的权限，包括channel:bot。不要随意添加权限范围：应将其与当前订阅方案及创建订阅所用的账号进行核对。

可以通过以下请求检查用户令牌的有效性和已授予的权限列表：

curl -H "Authorization: OAuth $BOT_OAUTH_TOKEN" https://id.twitch.tv/oauth2/validate

在响应中检查登录名、用户ID、有效期和scopes数组。如果缺少chat:read或user:read:chat，则需要使用所需的权限集重新授权。这种方案的缺点是需要替换机器人配置中的旧令牌和已保存的会话，否则它将继续使用原有权限运行。

分开诊断IRC和EventSub

IRC和EventSub通过不同途径传递消息。IRC通过持久连接传输聊天流：需要在原始日志中找到来自版主的PRIVMSG行。EventSub通过创建的API订阅传递channel.chat.message事件：这里要检查其状态、condition和传输方式。

如果机器人同时使用两个来源，请在日志中记录每个事件的来源。否则同一条消息可能被处理两次，而某个传输方式的故障会变得难以察觉。如果只使用EventSub，则没有IRC连接不算错误。EventSub方案的缺点是，当订阅错误或被禁用时，即使令牌有效，机器人也完全看不到消息。

检查聊天消息的EventSub订阅

在订阅列表中找到channel.chat.message事件。该记录必须处于活动状态。在condition中检查broadcaster_user_id——即主播频道的标识符——以及接收事件的用户的user_id。其中任何一个ID出错，往往表现为消息选择性地缺失。

通过GET /helix/eventsub/subscriptions请求订阅列表。在响应中检查type、status、condition和transport。状态enabled表示订阅处于活动状态；投递失败通知、已删除的记录或另一个频道都会指明原因。此请求应使用创建订阅的那个应用的令牌和Client ID。

不要只依赖面板或机器人数据库中是否存在记录。订阅可能是为测试频道创建的、在投递错误后被删除的，或者属于另一个应用。通过API检查的缺点是，它显示订阅配置，但无法解释处理程序内部的过滤逻辑。

启用IRC标签并检查作者角色

如果权限检查基于IRC，客户端必须请求twitch.tv/tags能力。没有标签，机器人可能收到文本和作者昵称，但看不到mod和badges字段。在这种情况下，普通命令能到达，而版主规则会给出错误的拒绝。

在版主的原始消息中查找mod=1和badges=moderator/1。user-type字段可能缺失、为空或与当前角色不符，因此不要将其作为唯一依据。解析器必须正确处理空的标签值和转义字符；IRC方法的缺点恰恰在于需要自行解析这种格式。

如果没有mod=1，首先确认标签能力确实已被服务器确认，而不仅仅是客户端发送了请求。然后检查badges。值moderator/1表示版主，broadcaster/1表示频道所有者。VIP通常具有vip/1徽章，但VIP不会自动成为版主。不应根据昵称、颜色或display-name将主播和VIP视为版主：角色应根据badges和单独的访问规则来确定。

检查代码和设置中的角色规则

比较来自观众、VIP、版主和频道所有者的相同文本的原始事件。如果版主的事件已到达应用，但处理程序将其跳过，则错误出在接收之后：角色检查、黑名单、反垃圾或命令路由中。

• 在比较之前将登录名统一为同一大小写。
• 检查mod=1和moderator徽章，而不是某一组固定标签。
• 分别定义broadcaster、moderator、vip和机器人自身账号的权限。
• 检查版主是否被列入忽略列表、封禁列表或禁止用户列表。
• 查看条件顺序：反垃圾或停用词可能在角色检查之前触发。
• 确认命令未被针对包含提及、链接或重复文本的消息的规则所阻止。

手动昵称列表仅适用于快速诊断。其缺点是，在版主更换、账号改名或频道角色变更后就会过时。

排除命令格式、限制和隐藏的忽略

机器人可能看到了消息却故意不回复。检查命令冷却时间、单个用户的消息限制、防重复保护、表情符号过滤器和停用词。版主经常快速发送命令，可能和观众一样触发反垃圾机制。

单独测试普通语句和带前缀的命令。如果语句在日志中，而命令未到达处理结果，请检查前缀、键盘布局、空格、不可见字符和参数。带斜杠的命令和版主操作并不总是以处理程序所期望的普通文本形式到达。

记录每条消息的决策原因

为便于诊断，保存时间、事件来源、频道、作者ID、消息类型、标签和处理结果。如果查找错误不需要文本，可以对其进行掩码处理。日志中应有具体原因：消息未收到、角色未识别、前缀未通过、触发冷却时间、用户被忽略或EventSub订阅被禁用。

不要在普通日志中记录OAuth令牌、应用密钥、webhook地址和完整的授权头。这些数据在调试时很方便，但泄露可能导致机器人及应用设置的访问权限被打开。

按顺序诊断的检查清单

1. 让观众和版主发送相同的语句和相同的命令。
2. 检查原始日志，确定消息是通过IRC、EventSub还是两个来源到达的。
3. 如果IRC未收到消息，核对机器人账号、频道名称、令牌和成功加入聊天的情况。
4. 如果IRC消息已到达，确认已启用标签，然后检查mod=1和badges=moderator/1。
5. 如果缺少mod=1，检查twitch.tv/tags的确认情况，并区分moderator/1、vip/1和broadcaster/1。
6. 通过validate检查令牌：IRC需要chat:read，EventSub消息需要user:read:chat。
7. 通过EventSub工作时，在订阅列表中检查channel.chat.message、enabled状态、condition和transport。
8. 比较角色处理、忽略列表、反垃圾、前缀、冷却时间和停用词。
9. 在日志中添加明确原因，说明每条消息被接受、忽略或拒绝的原因。