[Plugin] astrbot_plugin_DiscordToQQTransfer

[mmyddd]

插件信息

{
  "name": "astrbot_plugin_DiscordToQQTransfer",
  "display_name": "DiscordToQQTransfer",
  "desc": "一个用于在discord与qq之间转发与同步消息的 AstrBot 插件。",
  "author": "mmyddd",
  "repo": "https://github.com/mmyddd/astrbot_plugin_DiscordToQQTransfer",
  "tags": ["Discord","·消息转发"],
  "social_link": ""
}

插件检查清单

• 我的插件经过完整的测试
• 我的插件不包含恶意代码
• 我已阅读并同意遵守该项目的 行为准则。

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_DiscordToQQTransfer

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

代码质量与编码规范

• 内联导入不符合 PEP 8 规范：在 add_forward_log 方法中使用了内联导入 ts = __import__("time").time()。按照 PEP 8 规范，所有的标准库导入应当放置在文件的最顶部，建议改为在文件头部 import time。
• 组件实例化参数风格不一致：在 _forward_with_webhook 方法中，实例化 Plain 组件时直接传入了位置参数 Plain(f"<@{discord_sender_id}> ")，而在代码的其他地方（如 _forward_single_rule）通常采用关键字参数 Plain(text=f"...")。虽然两者在框架中可能都合法，但保持一致的编码风格可以提高可读性。

潜在缺陷或问题

• URL 扩展名判断逻辑脆弱：在 _forward_with_webhook 中判断 quote_text 是否为图片链接时，直接使用了 quote_text.endswith('.jpg') 等方法。这在实际网络环境中非常脆弱，因为图片 URL 经常带有查询参数（例如 https://example.com/image.jpg?size=1024）。建议引入 urllib.parse.urlparse 提取 URL 的 path 部分，然后再判断其后缀名。

---

webhook.py

代码质量与编码规范

• 缺少关键隐形字符注释：在 send_webhook_message 方法中，有 if not content: content = "​" 的逻辑。这里的字符串包含了一个零宽字符（\u200b），这是绕过 Discord 消息不能为空的巧妙方法。但这对于不知情的代码维护者来说，看起来就像是一个普通的空字符串或普通的空格。强烈建议添加注释说明此处使用的是零宽字符及其目的。

潜在缺陷或问题

• 模块级别的全局警告日志：在文件开头尝试导入 discord 库时，如果引发 ImportError，会直接在模块级别调用 logger.warning。这意味着，即使该插件（或用户侧）仅仅是加载了这个类而未实际使用自动创建 Webhook 功能，每次项目启动或重载导入此模块时都会打印警告，容易造成日志污染。建议将该警告延迟到 create_webhook_for_channel 方法被实际调用且发现缺少依赖时再输出。

---

代码评审团

Linus Torvalds：（皱着眉头，盯着屏幕）
“你在开什么玩笑？__import__("time").time()？这种在函数里动态导入模块的写法简直是在侮辱 Python 的解析器！如果我每次想知道时间都要动态查找一次模块表，Linux 内核早就崩溃一万次了。赶紧把你的 import time 给我老老实实地放到文件最顶端去。还有那些没加注释的零宽字符，你是想让接手你代码的人在 Debug 时把键盘砸了吗？写代码是为了让人读的，不要把这些当成你的恶作剧！”

Terry Davis：（狂热且快速地敲击着键盘）
“你看到了吗？上帝说万物皆有秩序，但你在解析图片 URL 的时候偏离了神圣的路径。你居然用 .endswith('.jpg') 来判断？当中央情报局在 URL 后面加上 ?tracking_id=666 的时候，你的图片转发就会像被诅咒一样失效！你应该用神圣的解析器（urlparse）剥离外表的伪装，直视 URL 的灵魂（路径）。而且你在 webhook.py 里用零宽字符欺骗了 Discord，这很像是一种发光的 CIA 戏法，不过很有趣，我喜欢这种黑暗魔法，但记得在旁边写上神圣的注释以免自己迷失。”

GLaDOS：（冷漠的机械音，带着一丝嘲讽）
“我注意到你对日志记录系统有着奇特的偏好。在 webhook.py 的最开头，哪怕测试对象根本不需要使用 Discord 库，你也要强迫系统播报一条警告日志。哦，这真是太体贴了，迫使每个人在启动时都要看到你的‘重要提醒’。如果这是为了做压力测试，用无用的日志塞满硬盘，那你做得非常棒。建议你把警告放到真正触发功能的地方，除非你真的很享受制造无意义的恐慌。”

Disclaimer: 以上评审内容由 AI 自动生成，仅提供审核参考，并无他意，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 2 个 Python 文件
• 已选择审核文件: 2 / 2
  已发送至 AI 审核的文件清单

main.py
webhook.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：mmyddd/astrbot_plugin_DiscordToQQTransfer
剩余触发次数：4

[mmyddd]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_DiscordToQQTransfer

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

• 代码质量与编码规范:

  • 模块导入位置不规范: 在 _forward_single_rule 方法内部有一句 from astrbot.core.message.message_event_result import MessageChain。按照 PEP 8 规范，所有的 import 语句应当统一放置在文件的顶部，以提高代码的可读性并避免在函数执行时重复触发导入检查。
  • 违反封装原则: 在 cmd_bind 方法内部，使用了 self.webhook_manager._get_discord_client()。单下划线前缀表示该方法是受保护的内部实现，不应当在类的外部直接被调用。建议在 DiscordWebhookManager 中提供一个公开的方法（如 get_discord_client()）。

• 功能实现与逻辑正确性:

  • 事件监听器签名违规: 装饰器 @filter.command_group("mt") 修饰的 mt 方法定义为 def mt(self):。根据框架规范，除了 on_astrbot_loaded 之外，所有使用 @filter 装饰的事件监听器方法，其签名中必须包含 event 参数。应修改为 def mt(self, event: AstrMessageEvent): 即使命令组本身可能不直接消耗它。

---

webhook.py

• 功能实现与逻辑正确性:

  • 存在 URL 参数拼接隐患: 在 send_webhook_message 方法中，拼接请求 URL 采用了 url = webhook_url + "?wait=true" 的方式。如果传入的 webhook_url 中已经携带了其他查询参数（例如 https://.../webhook?token=xxx），直接追加 ?wait=true 会导致产生非法的 URL 形如 ?token=xxx?wait=true。修复建议: 应当利用 aiohttp 提供的方法，即 session.post(webhook_url, json=payload, params={"wait": "true"}) 以保证请求的健壮性。

• 潜在缺陷或问题:

  • 宽泛的异常捕获与静默 (Silent Failure): 在 _try_extract_discord_client 内部出现了 except Exception: pass。捕获所有异常并静默通过会掩盖潜在的代码 Bug（如 AttributeError 或类型不匹配），这会给未来的调试和代码维护带来巨大困难。建议至少加上一条 logger.debug 记录异常。
  • 潜藏的 NameError 风险: 在 create_webhook_for_channel 底部进行了 except discord.Forbidden: 和 except discord.HTTPException: 捕获。尽管在方法开头有 if not HAS_DISCORD: return None 起到了卫语句的拦截作用，但从静态代码分析来看，如果后续维护者不慎移除了卫语句，在当前运行环境未安装 discord 库时，Python 解释器在执行到 except 语句时会直接抛出未捕获的 NameError: name 'discord' is not defined。

---

代码评审团

人物一：Linus Torvalds
我简直不敢相信我的眼睛。你在 webhook.py 里面硬生生地用加号拼接 URL 参数 webhook_url + "?wait=true"？你难道不知道 aiohttp.ClientSession.post 有一个叫 params 的参数专门用来处理这种事吗？万一别人给你的 URL 已经有参数了，你的请求就会直接连环爆炸！还有，在 main.py 里跨类调用 _get_discord_client() 的做法简直糟糕透顶，单下划线是给开发者看的警告，不是摆设，封装的概念被你丢到九霄云外了吗？

人物二：Steve Jobs
伟大的产品源于对细节的偏执与优雅的架构。当你把 import MessageChain 塞进一个长长的方法中间时，你破坏了代码的美感和呼吸感。所有的组件引用都应该在最开始被整齐、体面地陈列出来，而不是像个临时起意的补丁。至于那个 except Exception: pass……你这是在对不可预知的混乱妥协，真正的艺术家应该直面每一个异常并妥善处理它，这不是我们追求完美的态度。

人物三：理查德·斯托曼 (Richard Stallman)
你们大量依赖专有平台 Discord 的 API 虽然我不怎么提倡，但退一步说，你在代码中写 except discord.Forbidden: 时，有没有想过那些因为自由软件哲学而压根没有安装闭源生态库依赖的运行环境？虽然你的卫语句侥幸挡住了 NameError，但这种语法层面的耦合就像是给代码戴上了枷锁。你应该通过更安全的反射机制去处理异常类型的校验。保护代码的强壮度，就是保护用户的自由！

Disclaimer: 以上评审内容由 AI 自动生成，仅提供审核参考，并无他意，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 2 个 Python 文件
• 已选择审核文件: 2 / 2
  已发送至 AI 审核的文件清单

main.py
webhook.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：mmyddd/astrbot_plugin_DiscordToQQTransfer
剩余触发次数：3

[mmyddd]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_DiscordToQQTransfer

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

• 可维护性与可读性:

  • _forward_with_webhook 函数体过长（长达 120 多行），嵌套深度较高，包含了复杂的引述溯源、正则表达式匹配解析、多媒体附件判断以及网络请求等逻辑。这违反了单一职责原则（SRP）。建议将该函数拆分为多个独立的私有方法（如 _extract_quote_info, _build_discord_content 等），以大幅提高可维护性和可读性。

• 功能实现与逻辑正确性:

  • 在 MsgTransferStore.set_msg_mapping 方法中，当字典容量超过 MAX_MSG_MAPPINGS 时，会直接将字典前一半的数据删除。虽然在 Python 3.7+ 中字典是按插入顺序维护的，可以实现“淘汰老数据”的目的，但在后续 self._reverse_idx[str(discord_msg_id)] = qq_msg_id 中，并没有手动清除从 _reverse_idx 中对应的被删除键值，直到调用 self.save_msg_mapping(data) 内才触发 _rebuild_reverse_idx()。这种隐式的数据依赖较为脆弱，逻辑上存在一定割裂。

• 潜在缺陷或问题:

  • 存在潜在的并发写冲突：save_json 方法使用了写入 .tmp 临时文件再 .replace() 的机制来保证原子性。然而在异步并发环境下，同一时间可能会处理多条消息并触发并发保存，多个协程同时去写和替换 .tmp 文件可能会引发竞态条件导致数据丢失或文件读写异常（如 Windows 平台常见的权限占用的 OSError）。建议在文件写入相关操作上引入 asyncio.Lock() 来保证并发安全。
  • 数据淘汰机制带来的性能尖峰：load_msg_mapping 等字典大小达到上限时直接切除一半的元素，在长期运行的大规模群聊中，会产生反复触发大批量的字典遍历与 JSON 重写操作，增加不必要的 CPU 开销。考虑引入如 collections.OrderedDict 搭配细粒度的 LRU（最近最少使用）淘汰机制。

webhook.py

• 可维护性与可读性:

  • _search_platform_insts 和 _try_extract_discord_client 深度依赖框架的内部属性命名及内部实例结构（如使用 hasattr(platform_manager, 'platform_insts') 进而提取底层 client）。这种通过反射获取特定第三方模块实现的硬编码做法破坏了类的封装性，一旦框架核心代码进行重构或属性重命名，这些代码会立刻失效抛出异常。

• 代码质量与编码规范:

  • 像 MAX_CONTENT_LENGTH、MAX_USERNAME_LENGTH 这种常量定义在模块的全局作用域。既然它们仅用于 DiscordWebhookManager 类中的相关逻辑校验（如 _truncate_content），将其作为类的类属性（Class Attributes）更为合理，能增加模块的内聚性。

---

代码评审团

Linus Torvalds：看着那个一百多行的 _forward_with_webhook 函数，我的眼睛都要瞎了。你在一个函数里既做正则解析，又做引用对象重构，还要去发网络请求？拜托，函数是免费的，你不用花钱买，把它拆分一下好吗？还有那个暴力砍掉字典一半数据的操作，简直就像拿着电锯修剪盆栽，用个正经的缓存淘汰策略会要你的命吗？

Richard Stallman：你的 webhook.py 里到处都在反射寻找 platform_insts 里的 Discord client。这不仅是对封装的严重破坏，更绑定了特定的私有平台底层实现。我们应该追求通用自由的接口约定，而不是像黑客一样钻进别人的系统后院偷内部对象。万一别人重构了架构，你的代码就会变成一堆无用的破烂。

雷军：同学们啊，咱们做插件也要注重底层体验的打磨。你们看那个 .tmp 然后替换写入文件的逻辑，思路是对的，也是很巧妙的，但是在咱们高并发的异步环境里，不加锁是很容易翻车的，稍微用个 asyncio.Lock 保护一下，整个系统的稳定性“咵”一下就上去了，用户体验绝对是不一样的。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 2 个 Python 文件
• 已选择审核文件: 2 / 2
  已发送至 AI 审核的文件清单

main.py
webhook.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：mmyddd/astrbot_plugin_DiscordToQQTransfer
剩余触发次数：2

[mmyddd]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_DiscordToQQTransfer

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

• 功能实现与逻辑正确性 / 潜在缺陷

  • 并发读写的竞态条件风险 (Lost Update): MsgTransferStore 类中定义了 self._lock，但这把锁仅被用于保护最底层的 _write_json 操作。在如 add_rule、add_pending、pop_pending、set_msg_mapping 等众多状态修改方法中，获取数据的操作（如 self.load_rules()）并未加锁。在异步并发处理高频消息的场景下，极易发生多个协程同时读取旧数据并各自修改保存，从而互相覆盖导致数据丢失。建议将锁的作用范围扩大到整个“读取-修改-写入”事务。

• 安全漏洞与最佳实践 / 可读性与可维护性

  • 异常被静默吞没 (Silent Failure): 在 _resolve_reply_target 函数中，对 client.fetch_channel(channel_id) 的调用被放在 try...except Exception: pass 块中。捕捉所有异常且不进行任何日志记录是非常不推荐的做法。一旦因网络问题或 Discord API 权限问题导致调用失败，将很难排查追溯。应当至少打印一句 logger.warning。

• 潜在缺陷或问题

  • 模糊匹配的健壮性隐患: 在 list_rules 方法的 fuzzy_matches 逻辑中，仅仅使用了 endswith("_" + current_id_part) 和其反向比较进行匹配判断。当两端数据中因意外情况某一方非常短（如单一数字、字母甚至空字符串）时，可能造成大规模错误的错位匹配。建议进一步对拆分出的 id_part 增加有效性及长度验证。

---

webhook.py

• 潜在缺陷或问题

  • aiohttp.ClientSession 并发初始化导致连接泄露: 在 _get_session 异步方法中，if self._session is None or self._session.closed: 的非原子检查没有异步锁保护。如果在系统刚启动且消息密集涌入的瞬间，多个协程会同时判定为 None 并各自创建全新的 ClientSession。后续到达的赋值会覆盖先前的会话实例，从而使早期创建的会话在没有被显式 close() 的情况下被抛弃，造成 TCP 资源或底层描述符的隐性泄露。

• 可维护性与可读性

  • 严重违反封装与反模式的耦合设计: _get_discord_client 通过导入框架级组件 star_map，然后大范围遍历所有星体实例上下文，并使用 hasattr 硬编码去探测第三方模块对象底层的 client。这构成了典型的反模式。这使得插件与 AstrBot 的底层结构和其余插件形成了强耦合，如果框架平台管理的数据结构稍有重构，此处的脆弱逻辑将立刻崩溃。

---

代码评审团

人物一（Linus Torvalds）：我在 MsgTransferStore 里看到了什么？你弄了个 asyncio.Lock 放在写文件的末端，然后你在修改数据前先去无锁地读数据，修改完再去带锁地写？你这是在把锁当成心理安慰剂吗？在异步并发下，这种“读-修改-写”不加全局锁的做法，保证会让你的数据像被绞肉机碾过一样。把锁放到整个事务的外面去，别再写这种毫无常识的并发控制了。

人物二（Steve Jobs）：代码和艺术一样，需要优雅和直觉。当你为了获取一个 Discord Client，居然去遍历整个系统的 star_map，甚至用反射去强行探测别人的变量，这就像为了找一把锤子，你把邻居家的房子给拆了。这种设计极其丑陋且缺乏品味。你应该让数据顺滑地流入你需要的地方，而不是去系统底层翻箱倒柜。

人物三（罗永浩）：你看 _resolve_reply_target 里的那个 except Exception: pass。我们做产品讲究的是个体面和工匠精神，你把错误生吞活剥了，也不打个日志，连个招呼都不打。这就好比你在机器里留了个随时会炸的雷，然后跟用户说“没事，假装没看见就行”。这非常不讲究，加个 logger.error 很难吗？如果这是在实体硬件里，我早就把这代码砸了。

Disclaimer: 以上评审内容由 AI 自动生成，仅提供审核参考，并无他意，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 2 个 Python 文件
• 已选择审核文件: 2 / 2
  已发送至 AI 审核的文件清单

main.py
webhook.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：mmyddd/astrbot_plugin_DiscordToQQTransfer
剩余触发次数：1

[mmyddd]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_DiscordToQQTransfer

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

• 潜在缺陷与问题：

  • 危险的析构函数 (__del__)：在 __del__ 方法中尝试获取并操作事件循环（asyncio.get_event_loop_policy().get_event_loop()）是一个非常反模式和危险的做法。在 Python 中，对象被垃圾回收的时机是不确定的，如果在事件循环已经关闭或销毁时触发 __del__，将会抛出 RuntimeError，甚至导致程序崩溃或资源未能正确清理。既然该类已经实现了异步生命周期方法 async def terminate(self) 并且被框架调用，应彻底删除 __del__ 方法中对 webhook_manager 的处理。
  • _extract_quote_info 与 _resolve_forward_quote 的职责划分：这两个静态方法的逻辑紧密相关但又分离，涉及大量复杂的文本处理和正则表达式。正则表达式 re.sub(r'@[^\s(]+\(\d+\)\s*', '', parsed_text) 没有考虑可能的极端输入（如恶意的极长正则匹配目标），在大规模并发解析时存在轻微的 ReDoS（正则表达式拒绝服务）风险，建议在此正则上设定合理的长度限制。

• 代码质量与可读性：

  • 嵌套过深与过长的函数：list_rules 方法在进行模糊匹配时，包裹在一个巨大的 try-except 中，内部嵌套了多达五层的 if 与 for 循环，极大地降低了代码的可读性和可维护性。建议将模糊匹配逻辑（即对 parts 的拆分和对比部分）抽离为一个独立的私有方法，如 _fuzzy_match_rule。
  • 复杂的消息链构建逻辑：_forward_single_rule 方法包含了超过 50 行的逻辑用于拆解、拼接和发送消息链（MessageChain），职责过重。建议将消息构造部分（组装 Reply、At 和 Plain 等组件的代码块）提取出单独的函数进行处理。

---

webhook.py

• 可维护性与可读性：

  • 过度耦合框架内部实现：_search_platform_insts 函数直接访问了 platform_manager.platform_insts 的字典或列表结构。这属于强依赖宿主框架的底层内部实现结构，违背了面向对象的封装原则。一旦后续框架调整内部存储数据的结构，该插件将会抛出异常并失效。
  • 获取Discord客户端的方式不够优雅：方法 _try_extract_discord_client 同样依赖于鸭子类型来猜测某实例是否为 Discord 客户端（hasattr(client, 'user') 和 hasattr(client, 'get_channel')），这在缺乏强类型定义的情况下维护成本较高。

• 代码质量与编码规范：

  • 硬编码的魔法字符串与常量：build_virtual_username 函数中直接硬编码了 "aiocqhttp": "QQ" 的映射。如果未来引入其他平台适配器（如 satori），这里的映射则需要经常手动修改，建议将映射表设计为可配置的或全局静态变量。
  • 魔法零宽字符的硬编码替换：_sanitize_username 中使用插入零宽字符（\u200b）绕过 Discord 关键词审查的做法虽然有效，但这种“魔法”替换没有详细注释，容易让后续接手的开发者对该行代码感到困惑，建议补充相关背景说明的注释。

---

代码评审团

Linus Torvalds：老天，你到底明不明白 Python 的垃圾回收是什么时候被触发的？居然在 __del__ 里面写 asyncio.get_event_loop()？！当垃圾收集器在主线程或事件循环关闭之后来收走这个对象时，你的那段“智能”代码只会让整个进程吐出一串你根本不想看到的 RuntimeError 堆栈！把那段该死的 __del__ 代码删掉，乖乖用你的 terminate 方法！

Steve Jobs：看看你的 _search_platform_insts 是怎么写的。你把手直接伸进了框架的心脏里，去翻找 platform_manager 底层的字典和列表，这简直毫无优雅可言！优秀的软件工程应当建立在清晰、完美的接口之上。如果你过度依赖这种没有保障的内部结构，你的产品就像是用胶带粘起来的玩具，只要底层稍微升级一下，它就会分崩离析。

罗永浩：我就直说吧兄弟，你 list_rules 里的那个模糊匹配，五层缩进的 if-else 加一个超大的 try-except 兜底，写得实在是太粗糙了！这就像是一个师傅打磨家具，外面看起来还行，抽屉拉出来里面全是毛刺。做开发，工匠精神还是要有的，抽十分钟时间把这坨逻辑拆分成独立的小函数，不好吗？

Disclaimer: 以上评审内容由 AI 自动生成，仅提供审核参考，并无他意，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 2 个 Python 文件
• 已选择审核文件: 2 / 2
  已发送至 AI 审核的文件清单

main.py
webhook.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：mmyddd/astrbot_plugin_DiscordToQQTransfer
剩余触发次数：0