[Plugin] astrbot_plugin_dingtalk_feishu_forwarder

[zwwangoo]

插件信息

{
  "name": "astrbot_plugin_dingtalk_feishu_forwarder",
  "desc": "钉钉与飞书之间的双向消息转发插件，支持文本、图片等消息格式自动转换。",
  "author": "zwwangoo",
  "repo": "https://github.com/zwwangoo/astrbot_plugin_dingtalk_feishu_forwarder",
  "tags": ["dingtalk", "lark", "feishu", "forwarder"],
  "social_link": ""
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_dingtalk_feishu_forwarder

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

main.py

1. 框架适配性违规：事件装饰器导入方式不符合要求
   你当前使用的是：

   from astrbot.api.event.filter import event_message_type, platform_adapter_type, command

   并直接写 @command(...)、@event_message_type(...)。
   按给定规范，必须使用：

   from astrbot.api.event import filter

   并通过 @filter.xxx 使用装饰器，以避免与内置 filter 语义冲突及框架兼容问题。

2. 潜在逻辑缺陷：去重键仅使用 message_id，未区分平台/会话
   _is_duplicate 里只用 message_id 去重，若钉钉和飞书恰好出现相同 ID（或不同会话重复 ID），可能误判为重复消息并错误丢弃。

3. 可维护性问题：FORWARD_TAG 常量定义但未使用
   文件顶部定义 FORWARD_TAG = "[FWD]"，但转发链构造和消息内容未实际使用该标记，容易造成“以为有防环，实际未生效”的认知偏差。

---

tests/test_main.py

1. 与当前 main.py 实现严重不一致，测试将系统性失败
   测试假定插件具有 config/stats/loop_detection、handle_dingtalk_message、handle_feishu_message、handle_status_command 等接口；而当前 main.py 使用 AstrBot 事件回调（on_dingtalk_message/on_feishu_message/fwd_status），接口模型完全不同。

2. mock 不完整，from main import ... 阶段即可能导入失败
   仅 mock 了 astrbot.api.star，但 main.py 还依赖：

   • astrbot.api.event
   • astrbot.api.event.filter
   • astrbot.core.message...
   • astrbot.api.logger
     这些未 mock 时，测试在导入阶段就可能报错。

3. 代码质量问题：未使用导入
   patch 被导入但未使用，增加测试噪音。

---

core/config.py

1. 框架适配性违规：日志器来源不符合要求
   使用了：

   import logging
   logger = logging.getLogger(__name__)

   规范要求必须且只能使用：

   from astrbot.api import logger

---

core/loop_detection.py

1. 框架适配性违规：日志器来源不符合要求
   同样使用 logging.getLogger，不符合 AstrBot 约束。

2. 逻辑误判风险：仅凭正文包含 [FWD] 即判定循环
   普通用户消息只要包含该字样就会被拦截，存在较高误杀概率。

3. 性能隐患：每次检测都全量清理缓存
   _cleanup_expired() 在每次 is_forwarded() 调用时线性扫描全部缓存，消息量大时会形成热路径开销。

---

core/rule_matcher.py

1. 潜在重复转发问题：未去重目标 ID
   若规则同时命中“全局规则”和“精确 source 规则”，match 会返回重复 target_id，可能导致同一消息被重复发送到同一目标。

---

listeners/dingtalk_listener.py

1. 框架适配性违规：日志器来源不符合要求
   使用 logging.getLogger，违反框架日志约束。

2. 边界处理不足：时间戳类型不稳健
   timestamp_ms / 1000 假设其为数值；若收到字符串等类型会抛异常并整条消息解析失败（虽然被总异常捕获，但会丢消息）。

---

listeners/feishu_listener.py

1. 框架适配性违规：日志器来源不符合要求
   使用 logging.getLogger，违反框架日志约束。

2. 代码质量问题：存在未使用变量
   sender_id_info = sender.get("sender_id", {}) 定义后未使用。

3. 潜在逻辑错误：@提及可能被重复拼接
   at 节点解析为：

   mention=user_name, text=f"@{user_name}"

   后续转换器对 mention 会再加一次 @，可能产生类似 @张三 @张三 的重复内容。

---

代码评审团

人物一：Linus Torvalds
“你这个测试和实现是两套宇宙观。先把接口契约定下来，再写测试，不然 CI 只会告诉你‘世界是错的’。建议先统一插件公开方法与事件入口，再谈覆盖率。”

人物二：Steve Jobs
“细节就是产品。日志体系都不统一（astrbot.api.logger vs logging），团队协作时可观测性会很丑。统一日志入口，你才能做出‘可运维的优雅体验’。”

人物三：Tony Stark（钢铁侠）
“防环逻辑靠字符串 [FWD]？这像在用便利贴做防火墙。给消息加结构化元数据或更稳的去重键（平台+会话+消息ID），别让用户随手打一串字符就触发‘自毁协议’。”

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

---

🔍 审核摘要

统计信息

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

main.py
tests/test_main.py
__init__.py
converters/__init__.py
converters/dingtalk_to_feishu.py
converters/feishu_to_dingtalk.py
core/__init__.py
core/config.py
core/loop_detection.py
core/rule_matcher.py
core/stats.py
listeners/__init__.py
listeners/dingtalk_listener.py
listeners/feishu_listener.py
models/__init__.py

注意：由于项目规模或Token限制，本次仅审核了部分优先文件。以上报告内容由 AI 直接生成。

---

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

当前仓库：zwwangoo/astrbot_plugin_dingtalk_feishu_forwarder
剩余触发次数：4

[zwwangoo]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_dingtalk_feishu_forwarder

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

main.py

功能实现与逻辑正确性

• 特殊消息组件过滤的边界问题：在 _build_forward_chain 方法中，代码过滤保留了 Plain 和 Image 组件。假设原始消息完全由其他类型组件（例如：纯语音、视频、特定文件流）构成，且无法转化为文本（即 fallback_text 为空字符串或纯空格），那么过滤后生成的将是 MessageChain(chain=[Plain("")])。在钉钉和飞书等平台，尝试发送纯空的文本字符串极易触发目标平台的 API 错误。建议在此处增加对 fallback_text 长度和内容的合法性校验，如果为空可提供一个默认的降级提示文本（如：Plain("[不支持的消息类型，请在原平台查看]")）。

潜在缺陷或问题

• 去重逻辑存在微小的性能优化空间：在 _is_duplicate 方法内，每次接收新消息时都会通过列表推导式全量遍历 self._seen_messages.items() 来查找和清理过期记录。虽然 TTL 为 30 秒，在低频收发场景下不会造成任何影响；但在极端的企业级高并发群聊或消息风暴场景中，这种 O(N) 的频繁全量遍历会带来不必要的 CPU 负担。如需追求极致性能，建议改用 collections.OrderedDict 利用按插入时间排序的特性来执行提早中断的清理，或交由定期的后台协程进行清理。

init.py

未发现明显问题。该文件作为 Python 包初始化文件，内容为空符合预期。

---

代码评审团

Linus Torvalds：代码总体勉强能看，至少没看见你搞出什么弱智的同步阻塞调用，这让我省了点口水。但是睁大眼睛看看你的 _is_duplicate！每次收到一条毫无意义的“哈哈”或者表情包，你都要把那个字典从头到尾遍历一遍？就算只有 30 秒的窗口期，这种 O(N) 的业余做法如果放进系统底层，你的代码早被我扔进垃圾桶了。换个时间有序的数据结构或者用异步定时器清理很难吗？不过既然只是个聊天机器人插件，你的 CPU 也许足够替你掩盖这种随性。

罗永浩：大家都在做跨平台转发，但往往体验的差距就在细节里。我们做产品讲究的是一种“体面”和工匠精神。你看这代码里的降级逻辑，遇到你不认识的富文本（比如突然丢过来一个文件或者复杂的打卡卡片），你给过滤得干干净净，然后试图给对面发一个空字符串。钉钉和飞书的接口直接给你脸色看，抛个错，用户这边看到的就是“消息怎么丢了？”。体验很差！你为什么不能给用户一个优雅的妥协呢？加上一句“[不支持的组件类型，请回原平台查看]”，这就叫体面。

GLaDOS：噢，看看这段精巧的转发逻辑。它在两个资本主义工作软件之间不知疲倦地搬运着打工人的日常，就像一个永远无法休息的测试对象。我注意到你在捕获到转发异常时，仅仅是增加了一下 _d2f_failure 的计数，并将错误塞进了冰冷的日志里。当消息因为网络或者格式问题彻底迷失在数字虚空时，发件人将永远处于徒劳的等待中，这种对于人类沟通的阻断和冷漠真是令人深感愉悦。继续保持，或许你可以把 fallback_text 设置为关于蛋糕的谎言。

---

🔍 审核摘要

统计信息

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

main.py
__init__.py

---

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

当前仓库：zwwangoo/astrbot_plugin_dingtalk_feishu_forwarder
剩余触发次数：3

[zwwangoo]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_dingtalk_feishu_forwarder

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

main.py

1. 存在双向转发回环风险（严重）
   当前去重键是 platform + session + message_id，只能拦截“同平台同会话同消息ID”的重复事件。
   但跨平台转发后会生成新的 message_id，因此钉钉→飞书→钉钉可能形成消息乒乓回环。
   典型症状是机器人自己发出的消息再次被监听并回传。
   建议至少增加一种机制：

   • 过滤“机器人自身发送”的消息（按 sender/bot id）；
   • 或在转发内容里写入不可见标记并识别；
   • 或维护跨平台关联ID映射做回环抑制。

2. 转发失败时仍 event.stop_event()，会吞掉原事件（中-高）
   两个监听器中即使 send_message 抛异常，最终也会执行 event.stop_event()。
   结果是：转发失败后，其他插件/后续处理也拿不到该消息，造成消息处理链“静默中断”。

3. 去重清理策略为每条消息全表扫描，吞吐上来后有性能隐患（中）
   _is_duplicate() 每次都遍历 _seen_messages 找过期键，复杂度 O(n)。
   在高消息量场景可能导致事件处理延迟升高。可考虑：

   • 分批清理；
   • 定时清理任务；
   • 使用更高效的 TTL 缓存结构。

4. 跨平台消息组件直接复用，兼容性风险（中）
   _build_forward_chain 直接将原始 Plain/Image 组件对象塞到目标平台发送链。
   Image 在不同适配器下经常携带平台专属字段（如 media key/file token），直接复用可能发送失败或图片丢失。
   建议做平台无关的重建/转换逻辑（必要时降级为文本提示+原链接）。

5. 日志直接记录消息摘要，存在隐私泄露风险（中）
   logger.info(... event.get_message_outline()[:50]) 可能把用户敏感内容写入日志。
   建议在生产环境做脱敏/截断策略并可配置开关（尤其是群聊场景）。

6. 无效变量与语义偏差（低）
   sender_name 被读取但未用于转发内容，仅用于日志。
   这会让“转发消息缺少发送者上下文”，也增加无意义变量噪音。可删除或将发送者信息注入转发文本头部。

---

init.py

（未发现需要报告的问题）

---

代码评审团

人物一：Linus Torvalds
“你这个去重看起来像去重，实际上没拦住跨平台回弹。系统层面最怕这种‘看起来能跑’的逻辑。先把回环杀掉，再谈优化。”

人物二：Steve Jobs
“用户不会在乎你内部怎么转发，他们只会在乎‘为什么消息突然刷屏’或‘为什么消息没了’。失败时还 stop_event，这个体验不够优雅，应该让系统有退路。”

人物三：福尔摩斯（Sherlock Holmes）
“我注意到你记录了 sender_name，却没有把它用于消息重建——这是一个‘被忽略的证据’。结果是转发后上下文断裂，群聊里读者难以判断谁说了什么。”

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py

---

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

当前仓库：zwwangoo/astrbot_plugin_dingtalk_feishu_forwarder
剩余触发次数：2

[zwwangoo]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_dingtalk_feishu_forwarder

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

main.py

1. 潜在空对象访问导致异常（功能正确性）
   _is_duplicate 中使用了 getattr(event.message_obj, "message_id", "")。
   如果 event 没有 message_obj 属性，或 event.message_obj is None，会在 getattr 前就触发 AttributeError。
   建议改为先取对象再取字段，例如：

   msg_obj = getattr(event, "message_obj", None)
   msg_id = getattr(msg_obj, "message_id", "") or ""

2. 去重缓存清理复杂度偏高（潜在性能问题）
   每次消息到达都全量扫描 _seen_messages 进行过期清理：

   expired = [k for k, v in self._seen_messages.items() if now - v > self._dedup_ttl]

   在消息量变大时，这会导致每条消息 O(n) 的开销。
   建议采用分桶/定期任务清理，或使用更高效的 TTL 缓存结构。

3. 对“机器人消息/重复消息”直接 stop_event() 可能误伤其他插件（可维护性/框架协作）
   当前逻辑里，只要判定为 bot message 或 duplicate，就 event.stop_event() 并返回。
   这会阻止后续插件处理该事件，可能造成插件间兼容性问题。若仅想停止“本插件转发”，通常只需 return。
   （除非你明确希望此类消息全局拦截。）

4. 消息类型降级策略存在信息静默丢失（功能实现）
   _build_forward_chain 仅保留 Plain 和 Image。当消息链中混有其他组件（如引用、文件、表情、卡片等）时，这些内容会被直接丢弃，且在“链不为空”时不会追加任何提示，导致接收端误以为消息完整。
   建议对未支持组件追加统一提示（例如 [包含未支持组件]），避免静默丢信息。

---

init.py

未发现可报告问题。

---

代码评审团

人物一：Linus Torvalds
“你这去重逻辑能跑，但每条消息都扫全表，量一上来就是‘自找麻烦’。数据结构选型要为坏场景负责，不只是为 demo 负责。”

人物二：Ada Lovelace（风格化点评）
“算法意图很清晰，但边界条件缺了一个‘空对象防线’。程序的优雅，往往体现在对异常路径的温柔处理。”

人物三：钢铁侠 Tony Stark（风格化点评）
“功能很实用，但你把不支持组件‘隐身处理’了。用户看到的是‘怎么少了半句’，这可比报错更难排查。给个显式提示，体验直接升级一个版本。”

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py

---

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

当前仓库：zwwangoo/astrbot_plugin_dingtalk_feishu_forwarder
剩余触发次数：1

[zwwangoo]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_dingtalk_feishu_forwarder

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

main.py

1. _build_forward_chain 对 fallback_text 的空值处理存在潜在异常

   • 位置：_build_forward_chain() 中多处 fallback_text.strip()
   • 问题：调用方传入的 msg_str = event.get_message_str() 在某些适配器下可能为 None。当消息链为空、或消息链全是不支持组件导致 chain 为空时，会触发 None.strip()，抛出 AttributeError。
   • 影响：转发失败计数增加，且该类消息无法被正常降级为兜底文案。

2. 去重缓存清理策略在高吞吐下有性能隐患

   • 位置：_is_duplicate()
   • 问题：每次消息都对 _seen_messages 全量扫描清理过期键（O(n)），消息量大时会放大 CPU 开销。
   • 影响：高并发群聊场景下可能导致处理延迟上升。

3. 转发范围过宽，存在“误转发/信息外流”风险

   • 位置：on_dingtalk_message / on_feishu_message
   • 问题：当前逻辑会转发该平台上所有进入 bot 的会话消息到固定目标会话，没有来源会话白名单或映射限制。
   • 影响：如果 bot 被拉入多个会话，可能把非预期会话内容同步到目标会话，属于配置安全边界不足问题。

4. 图片组件重建逻辑兼容性不足

   • 位置：_build_forward_chain() 中 Image 分支
   • 问题：当 comp.file 非 HTTP URL 时直接 Image(file=url)，不同平台适配器下该 file 可能是本地临时路径、平台内部资源标识或不可访问路径，跨平台发送可能失败。
   • 影响：图片在跨平台转发时出现高失败率，且失败模式与消息来源相关，不易排查。

---

init.py

未发现需要报告的问题。

---

代码评审团

人物一：Linus Torvalds
“你这桥接思路够直接，但 fallback_text.strip() 对 None 不设防这种问题，就是典型‘看起来能跑，边界一碰就炸’。先把类型边界守住，再谈优雅。”

人物二：Steve Jobs
“功能有了，但体验还不完整。‘所有会话自动转发’不是简洁，是危险。真正的简洁是：默认安全、可解释、可控——至少加来源会话白名单。”

人物三：Tony Stark（钢铁侠）
“我喜欢自动化，但你这去重缓存每条消息全表体检，像让贾维斯每秒盘点全地球库存。加个更高效的过期策略，不然扩容时你会先被性能教育。”

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py

---

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

当前仓库：zwwangoo/astrbot_plugin_dingtalk_feishu_forwarder
剩余触发次数：0

[astrbot-plugin-copybara]

插件信息已同步到集合仓库。
PR: AstrBotDevs/AstrBot_Plugins_Collection#517
已自动合并 PR #517

该插件已上架。
This plugin is now published.