[Plugin] astrbot_plugin_bili_resolver

[chufeng]

插件信息

{
  "name": "astrbot_plugin_bili_resolver",
  "display_name": "Bilibili 小程序原链解析",
  "desc": "Bilibili的小组件最麻烦了，电脑打不开，于是做了个可以直接转成原链接和展示播放和介绍的工具",
  "author": "chufeng",
  "repo": "https://github.com/chufeng/astrbot_plugin_bili_resolver",
  "tags": [
    "Bilibili",
    "B站",
    "转链"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_bili_resolver

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

main.py

代码质量与规范

• PEP 8：全局常量与函数之间缺少空行（例如 IMAGE_SUFFIXES 后直接定义函数），多处超长行（长正则、长字符串拼接、装饰器参数）影响可读性与 diff 友好性。
• 命名/类型不一致：
  • IMAGE_SUFFIXES 内容混杂（.jpg 带点、jpeg/jfif/webp 不带点），且 _is_image() 只取 msg[-4:] 判断，导致 .jpeg、.webp、.jfif 等永远无法命中，.png 等也依赖恰好 4 位后缀才行。
  • _is_image() 的判断方式过于脆弱，遇到带 query 的图片 URL（如 xx.png?x=1）会误判为非图片。
• _format_msg() 对非 http 的图片 URL 直接拼 https:{i}：若传入的是相对路径、或不是以 // 开头的 URL，可能生成无效链接（例如 https:abc）。

功能实现与逻辑正确性

• BILI_PATTERN 中包含 ^ 锚点片段（(^(av|cv)(\d+))|(^BV...)），但使用的是 search() 而非 match()：
  这会造成“只有在整条消息开头出现 av/cv/BV 才能被识别”，中间出现时无法触发，与用户实际粘贴习惯不一致。
• _extract_from_raw_message() 的 CQ 码解析正则：r'\[CQ:json,data=(.*?)\]'
  • 若消息中包含多个 CQ 段或嵌套 ]，可能截断/提取不全；
  • 仅做了有限 HTML 实体替换，对实际 OneBot/CQ 编码差异的兼容性不足，导致“有卡片但提取不到链接”的边界问题。
• on_message() 中 event.stop_event() 的使用比较激进：即使解析失败/异常也 stop，会吞掉后续插件或框架默认处理，在群里可能表现为“这条消息被插件拦截但什么也没发”。

异步与性能/稳定性

• 每条消息都会新建 aiohttp.ClientSession（on_message/search_video），在高并发群聊会产生明显开销（连接池复用差、TLS 握手频繁），建议复用 session（例如在插件生命周期内维护一个 session，并在 terminate() 关闭）。
• 所有 session.get() 调用均未设置超时（timeout），网络抖动时会导致协程长时间悬挂，拖慢事件循环。
• 仅对异常做了兜底日志，缺少对 HTTP 状态码的显式检查；上游返回非 200 时，resp.json() 等可能抛异常或返回非预期结构。

安全与最佳实践

• 允许从消息中提取 URL 并请求，虽然仅针对 bilibili 域名的弱判断，但仍建议：
  • 对提取到的 json_url 做更严格的域名白名单校验（netloc 精确匹配），避免被构造 bilibili 字符串的恶意域名绕过（例如 bilibili.evil.com 这类）。
• @register(...)：在部分 AstrBot 版本中已属于“可选/不推荐”的注册方式（框架可自动识别 Star 子类）。这不一定会立刻出错，但会带来未来兼容性与重复注册风险（视框架加载策略而定）。

---

init.py

• 文件为空：如果这是有意为之没问题；但若期望作为包导出入口，当前未显式导出任何符号，可能导致 IDE/类型检查对外部可见性较差（取决于项目结构与发布方式）。

---

analysis_bilibili.py

框架适应性（严重）

• 违规日志用法：使用了 Python 内置 logging 并 logging.getLogger(...)：
  按要求 logger 必须且只能 from astrbot.api import logger。这会导致日志体系不统一、插件日志配置失效或重复输出。

功能实现与逻辑正确性

• b23_extract()：
  • 未检查正则是否匹配成功：b23 = re.compile(...).search(...) 可能为 None，随后 b23[0] 会直接 TypeError。
  • 未检查响应状态码；直接 return str(resp.url)，遇到 4xx/5xx/反爬跳转会得到非预期 URL。
• search_bili_by_title()：
  • assert resp.status == 200 在生产环境不可靠：断言可能被优化参数禁用，且断言失败会抛 AssertionError（被上层吞掉后只返回“出错”，定位困难）。
  • 函数签名标注返回 str，但多处 return None，类型与实际不符；调用方若按字符串处理会出错或产生隐性分支。
• handle_num()：标注返回 str，但 num <= 10000 时原样返回 int，类型不一致会污染后续拼接/序列化逻辑。
• dynamic_detail()：
  • res = res.get("data").get("item")：若 data 为 None 会触发 AttributeError。后续大量深层索引（res["modules"]["module_dynamic"] 等）也缺少健壮性判断，遇到结构变更/权限动态会频繁异常。
• bangumi_detail() 参数 time_location: str，实际调用链传入的是 re.Match 或 None；内部又使用 time_location[0]，类型注解与真实类型不符，影响维护与静态分析。

异步与性能/稳定性

• 全文件的所有 HTTP 请求均未设置 timeout、未做 resp.status 检查，且大量 await resp.json() 假设返回必为 JSON：在反爬/风控/网关异常时会导致异常风暴。
• analysis_stat 作为全局 dict，用于去重：
  • 无上限增长（群越多、链接越多越占内存）；
  • 异步并发下可能出现竞态（同群并发消息时判断与写入非原子），导致去重失效或覆盖。
• 多处 except Exception as e: 仅返回 type(e)，丢失关键信息（message、堆栈），排障困难。

代码质量与可维护性

• 大量函数返回类型不一致：例如标注 Tuple[List[str], str]，但实际可能返回 (str, url)、(None, None) 等，调用方若不做严格分支会产生隐式 bug。
• 全局可变配置（analysis_display_image, analysis_display_image_list, images_size 等）由外部模块直接改写，跨群/跨会话共享状态，很容易出现“某次配置影响全部群”的不可预期行为。

---

wbi.py

异步与性能/稳定性

• getWbiKeys() 每次调用都会创建一个新的 ClientSession 并访问 nav 接口；而 get_query() 每次签名都调用 getWbiKeys()：
  这会导致搜索/解析请求成倍增加（一次业务请求先 nav 再 search），高频触发时对性能和被风控概率都不友好。建议缓存 img_key/sub_key（带过期时间）并复用 session。
• 未设置 timeout、未检查 resp.status、未处理非 JSON 响应，网络/风控场景下容易卡住或抛异常。

代码质量与规范

• 函数命名不符合 PEP 8：getMixinKey/getWbiKeys/encWbi 应使用 snake_case（例如 get_mixin_key）。
• lambda chr: ... 使用 chr 作为变量名会遮蔽内置 chr()，降低可读性与可维护性。
• 缺少类型标注（例如 getMixinKey、encWbi、getWbiKeys），与其他文件的部分类型标注风格不统一。

---

代码评审团

人物一（Linus Torvalds，毒舌但务实）
你这堆 except Exception 就像把保险丝换成铁丝：短期“不断电”，长期炸得更狠。至少把 resp.status、响应内容、以及异常堆栈打出来；再不济也别只打印 type(e)。另外全局 dict 去重不设上限，是打算让机器人陪群聊一起“内存修仙”吗？

人物二（Guido van Rossum，偏语言与可读性）
类型注解写了但没用到位：handle_num() 返回 int 或 str、search_bili_by_title() 标 str 却返回 None、还有 time_location: str 实际上传 Match。这会让维护者（包括未来的你）在阅读时不断“推理实际类型”。建议统一返回类型（例如 Optional[str]、str | None），并把 Match 早一点转换成纯字符串。

人物三（Steve Jobs，体验与产品导向）
用户体验上最大的问题是：你在 on_message() 里动不动就 stop_event()，但失败时又可能啥也不发。结果就是“机器人看起来很聪明地拦截了一切，然后沉默”。把 stop 的条件收紧：只有当你确实成功输出了内容，或者明确告诉用户失败原因时再 stop，否则别抢别人的舞台。

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
analysis_bilibili.py
wbi.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[chufeng]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_bili_resolver

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

main.py

代码评分: 95/100

审查报告:

1. 代码质量与编码规范:

   • 整体代码结构清晰，遵循 PEP 8 规范。
   • 导入结构正确，严格遵守了 AstrBot 的框架要求。
   • BilibiliAnalysis 类正确继承自 Star，且注册方式符合规范。

2. 功能实现与逻辑正确性:

   • 逻辑实现稳健，涵盖了 JSON 卡片提取、CQ 码兼容、纯文本解析等多种消息格式。
   • on_message 和 search_video 的事件监听器签名正确（self, event: AstrMessageEvent）。
   • 异步网络请求使用了 aiohttp，且正确复用了 ClientSession（在 main.py 层面）。

3. 框架适应性检查:

   • 日志记录: 正确使用了 from astrbot.api import logger。
   • 并发模型: 没有发现同步阻塞的网络 I/O。

4. 可维护性:

   • 正则 BILI_PATTERN 较为复杂，建议添加注释说明各捕获组的用途，便于后续维护。

5. 潜在缺陷:

   • 无明显缺陷。

---

analysis_bilibili.py

代码评分: 80/100

审查报告:

1. 框架适应性检查 (严重):

   • 日志记录违规: 代码中使用了 import logging 和 logger = logging.getLogger("astrbot_plugin_bilibili_analysis")。这是明确禁止的。
   • 修正建议: 必须移除 import logging，并改为 from astrbot.api import logger。

2. 代码质量与编码规范:

   • 函数 resize_image 中 img_type = src[-3:] 这种切片方式过于脆弱。如果图片后缀是 .jpeg 或 .webp（4个字符），截取结果将是 peg 或 ebp，导致生成的 URL 格式错误（如 .webp@size.ebp）。

3. 潜在缺陷与资源管理:

   • 内存泄漏风险: 全局变量 analysis_stat 用于防止群内重复解析，但它是一个只增不减的字典。对于长期运行且群组众多的 Bot，这会导致内存缓慢泄漏。建议改为使用 LRU Cache (如 functools.lru_cache 或手动实现的定长字典) 或者定期清理机制。

4. 功能实现:

   • 错误处理较为粗糙，多处直接捕获 Exception 并返回错误信息的字符串。虽然保证了不崩溃，但可能会掩盖一些编程错误。

---

wbi.py

代码评分: 85/100

审查报告:

1. 潜在缺陷与性能问题:

   • Session 创建开销: getWbiKeys 函数内部直接使用 async with ClientSession(headers=HEADERS) as session: 创建了新的会话。
   • 在 analysis_bilibili.py 的 search_bili_by_title 中，虽然已经持有一个 session 对象，但在调用 get_query -> getWbiKeys 链路时并没有传递这个 session。
   • 这意味着每次进行视频搜索，都会触发一次完整的 SSL 握手和连接建立过程来获取 WBI Key，效率较低。建议修改 getWbiKeys 和 get_query 签名以接受 session 参数。

2. 功能实现:

   • WBI 签名算法实现逻辑正确。

---

init.py

代码评分: 100/100

审查报告:

• 文件为空，符合作为 Python 包标识文件的常规用法，无问题。

---

代码评审团

人物一：Linus Torvalds
“我在 analysis_bilibili.py 里看到了什么？import logging？你是看不懂文档还是故意想惹恼框架开发者？那个 Logger 规则写得清清楚楚！还有 wbi.py，你居然在每次获取 Key 的时候都创建一个新的 ClientSession？你是不是觉得 TCP 握手和 SSL 协商是免费的？把 Session 传进去复用！这是网络编程的第一课！”

人物二：GLaDOS (Portal)
“看我在 analysis_bilibili.py 发现了什么... 一个 analysis_stat 全局字典。它在不断地吃掉内存，永远不会释放。就像那个被你们遗忘在角落里的同伴方块。这非常... 迷人。等到你的 Bot 因为内存耗尽而崩溃时，请记住，这都是为了科学。另外，那个图片后缀截取代码写得真是‘天才’，我敢打赌它处理 .webp 文件时的表现一定很有趣。”

人物三：Steve Jobs
“这个插件的功能是好的，它解决了用户在移动端无法预览 Bilibili 视频的痛点。但是代码的‘品味’还需要打磨。main.py 里那一堆正则表达式和针对 OneBot 原始消息的解析逻辑，太不优雅了。这就像是在手机背面贴了一层胶带。虽然 AstrBot 已经封装了很好的对象，但你还是深入到了 raw_message 的泥潭里。不过，至少它能运行，用户体验是对的，这点值得肯定。”

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
analysis_bilibili.py
wbi.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[astrbot-plugin-copybara]

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

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