[Plugin] astrbot_plugin_parserURL

[Ishning]

插件信息

{
  "name": "astrbot_plugin_parserurl",
  "display_name": "社交媒体链接自动解析插件",
  "desc": "社交媒体分享链接解析插件。将A站、B站、抖音、小红书、微博...等网站的视频、图集、音频进行解析并发送",
  "author": "Ishning",
  "repo": "https://github.com/Ishning/astrbot_plugin_parserURL",
  "social_link": "https://github.com/Ishning"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_parserurl

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

main.py

1. 持久化路径与插件名硬编码且不一致

   • save_to_plugin_config() 中硬编码了：
     • plugin_name = "astrbot_plugin_parserURL_config"
     • config_path = "data/config/{plugin_name}.json"
   • 与 PluginConfig 里的 _plugin_name = "astrbot_plugin_parserurl" 命名不一致（大小写与后缀都不同），存在写错配置文件的高风险，导致订阅数据“写了但插件实际不读”。

2. save_to_plugin_config() 直接写全局配置文件，缺少并发写保护

   • 多个管理员并发执行“订阅/取消订阅”时，可能发生覆盖写（last write wins），产生订阅丢失。

3. 命令入口缺少“解析器未启用”保护

   • login_bilibili / subscribe_bili_up / unsubscribe_bili_up / 查询命令都直接 _get_parser_by_type(BilibiliParser)，若 Bilibili 解析器未启用会抛 ValueError，影响命令稳定性。

4. 仲裁上下文字段读取存在 KeyError 风险

   • raw["message_id"] / raw["time"] / raw["self_id"] 直接索引，若上游协议字段缺失会直接异常中断。

---

core/arbiter.py

1. 网络异常被当作“无人点赞”处理，可能误判胜出

   • _fetch_users() 出错直接返回 []，在 compete() 里会被解释为“无竞争者”，可能导致网络抖动时错误触发解析。

2. 缺少单次仲裁超时控制

   • 多次依赖 bot API 调用与 sleep，若平台接口卡住会拉长事件处理链路，影响异步环境吞吐。

---

core/clean.py

1. stop() 未真正关闭调度器

   • 仅 remove_all_jobs()，未 shutdown()，插件卸载后调度器资源仍可能驻留，存在资源泄漏风险。

2. 清理逻辑对不存在目录不做前置判断

   • shutil.rmtree(self.cfg.cache_dir) 在目录不存在时抛异常，虽被捕获，但会产生无意义异常日志。

---

core/config.py

1. enabled_platforms() 的默认启用逻辑可能失效

   • getattr(v, "enable", True) 对 ConfigNode 字段常返回 None（而非抛 AttributeError），None 被当作 False，导致“未显式配置 enable”时平台可能被错误禁用。

2. StarTools 导入路径不符合框架约束

   • 当前使用 from astrbot.core.star.star_tools import StarTools，不符合约束中建议的 astrbot.api.star 入口。

---

core/cookie.py

1. 敏感信息泄露风险（日志）

   • update_from_response() 会 debug 记录完整 Set-Cookie 与 value，可能泄露会话凭据（cookie/token）。

2. to_dict() 对脏数据不健壮

   • 直接 cookie.strip().split("=", 1)，遇到非法片段会 ValueError，缺少容错分支。

---

core/data.py

1. async @property 设计导致调用复杂且易误用

   • ParseResult.cover_path 定义为异步属性，调用方需特殊处理 awaitable，已在渲染层出现“手动探测 __await__”的补丁式代码，维护成本高、易出错。

2. get_resource_id() 缓存与可变对象冲突

   • 计算后缓存 _resource_id，但 ParseResult/contents 后续可被修改，可能产生陈旧指纹，导致资源防抖误判。

3. 多处 __repr__ 使用变量名 repr

   • 覆盖内建名 repr，可读性与规范性较差。

---

core/download.py

1. proxy 默认值使用 ...（Ellipsis）存在实参污染风险

   • streamd() 和若干下载方法默认 proxy=...，若调用链未覆盖会把 Ellipsis 传给 aiohttp，触发类型错误。

2. ytdlp_* 下载流程缺少体积限制校验

   • 流式下载有大小限制，但 yt_dlp 路径未见同级限制，可能下载超大文件导致磁盘压力。

3. yt_dlp 下载异常未统一包装

   • 多处直接 to_thread(ydl.download, ...)，失败时异常类型分散，调用层难以一致处理。

---

core/render.py

1. 对类级资源加载顺序有隐式依赖

   • fontset/platform_logos/video_button_image 依赖 load_resources() 预加载；若初始化流程异常或遗漏，将在渲染时触发属性缺失错误。

2. 异常吞噬范围过大

   • suppress_exception / suppress_exception_async 广泛返回 None，会掩盖真实 bug，表现为“渲染内容默默缺失”，排障困难。

3. _calculate_sections() 中的 awaitable 探测是脆弱实现

   • 通过 hasattr(_cover, "__await__") 判定是否可 await，说明数据模型接口不清晰，易引入边界错误。

---

core/sender.py

1. 发送计划默认强制渲染卡片

   • _build_send_plan() 里 render_card = True，无条件启用，导致渲染成本恒定增加，也使配置项可控性下降。

2. 主动推送 bot 选择逻辑不正确

   • platform_botid 存在时始终取 platform_botid[0]，对多平台场景会错绑机器人身份。

3. 可能构造非法 Node

   • Node(uin=bot_self_id, ...) 中 bot_self_id 可能为 None，存在平台侧参数校验失败风险。

---

core/utils.py

1. extract_json_url() 对 meta[key1] 类型假设过强

   • meta.get(key1, {}).get(key2) 假设二级节点是 dict；若上游给了非 dict 会抛异常，缺少类型保护。

2. 外部进程执行无超时控制

   • exec_ffmpeg_cmd() 等待 process.communicate() 无 timeout，ffmpeg 卡住会长期占用协程与系统资源。

---

代码评审团

人物一：Linus Torvalds
“async property 这种接口设计让调用方去猜对象是不是 awaitable，等于把复杂度倒给每个调用者。接口就该‘一眼看懂’，别让 _calculate_sections() 写出 hasattr(__await__) 这种补丁。”

人物二：Steve Jobs
“你这套发送链路功能很多，但‘默认总渲染卡片 + 再发媒体’让体验不够克制。好的产品是‘默认路径优雅’，不是每次都把 GPU/CPU 拉满。把默认行为收敛，用户会更爱它。”

人物三：Geralt（利维亚的杰洛特，虚拟角色）
“我闻到了危险的味道：日志里打印完整 Set-Cookie。这不是银剑，是自伤。凭据一旦进日志，就像怪物进村子——早晚出事。先把敏感字段打码，再谈狩猎。”

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

---

🔍 审核摘要

统计信息

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

main.py
core/__init__.py
core/arbiter.py
core/clean.py
core/config.py
core/constants.py
core/cookie.py
core/data.py
core/debounce.py
core/download.py
core/exception.py
core/render.py
core/sender.py
core/utils.py
core/parsers/__init__.py

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

---

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

当前仓库：Ishning/astrbot_plugin_parserURL
剩余触发次数：4

[Ishning]

@astrpluginreviewer reviewer

[astrpluginreviewer]

❌ 插件审核失败

您好！在对您的插件进行审核时遇到了问题：

调用AI审核服务时发生内部错误。

---

请根据上述问题进行修改。修改完成后，请在 Issue 正文 中勾选"重新提交审核"复选框以再次触发审核。

此消息由系统自动生成

当前仓库：Ishning/astrbot_plugin_parserURL
剩余触发次数：4

[Ishning]

@astrpluginreviewer reviewer

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_parserurl

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

main.py

• 数据持久化: save_to_plugin_config 方法中硬编码了保存路径 config_path = f"data/config/{plugin_name}_config.json"。按照框架最佳实践，应通过导入 StarTools 并调用 StarTools.get_data_dir() 来获取规范的数据存储目录（返回值为 Path 对象），避免使用硬编码路径或基于 os.path 拼凑路径。

core/arbiter.py

• 可维护性与潜在缺陷: compete 及 _fetch_users 方法中使用了直接捕获所有常规异常的 except Exception: 语句。这种过于宽泛的捕获范围可能会掩盖诸如变量名拼写错误、类型错误等预期之外的严重 Bug，增加后期问题排查的难度。建议针对预期可能会抛出的异常类型（如特定网络请求异常）进行精准捕获，或至少在日志中记录完整的异常信息（logger.exception）。

core/render.py

• 潜在缺陷或问题: 文件中存在大量基于 Pillow (PIL) 的图片绘制与处理操作（例如图片缩放 resize、裁剪、文本绘制等）。图片处理属于典型的 CPU 密集型任务，当处理较多或较大图片时，直接在主事件循环中同步执行会导致异步事件循环阻塞，降低框架响应其它并发事件的能力。建议将 CPU 密集型的渲染操作封装为函数，并通过 asyncio.to_thread() 交由后台线程池执行。

core/utils.py

• 代码质量与编码规范: fmt_size 函数的文档字符串（Docstring）中参数描述为 video_path (Path): 视频路径，而其实际的函数签名形参为 file_path: Path。参数命名未保持一致，可能在 IDE 调用提示中误导使用者，建议修正统一。

---

代码评审团

Linus Torvalds：老天，看看 core/utils.py 里那个函数的注释。你的参数叫 file_path，注释偏要写个 video_path？你连复制粘贴代码时顺手改一下注释的力气都不愿意出吗？另外，core/arbiter.py 里的 except Exception: 简直是个灾难，直接把异常吃掉还不留半点痕迹，等到以后调试找不出原因时，你只会恨不得扇自己两巴掌。赶紧修了，别拿这种低级失误浪费别人的时间。

乔布斯：我们追求的是极致的丝滑体验。但我在 core/render.py 里看到了什么？你居然在负责监听所有呼吸和心跳的主事件循环里去一块一块地拼凑像素点！这些图片渲染操作严重阻塞了整个机器人的响应神经，当多用户同时触发时，卡顿带来的体验简直是一场灾难。把那些繁重的图像绘制丢给线程池吧，保持主线程的绝对纯净和优雅，这才是完美的架构艺术。

罗永浩：说实话，看到 main.py 那个硬编码的路径我是很心痛的。一个现代化的插件框架，给你提供了 StarTools.get_data_dir() 这么体贴好用的接口，你不用，非要手写 data/config/...。这是典型的“凑合能跑就行”的思想。我们做软件，讲究的是一种工匠精神啊朋友们，API 给你铺好了路，顺着走，不要在框架里到处拉屎撒尿，稍微注重一下工程美学好不好？

---

🔍 审核摘要

统计信息

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

main.py
core/__init__.py
core/arbiter.py
core/clean.py
core/config.py
core/constants.py
core/cookie.py
core/data.py
core/debounce.py
core/download.py
core/exception.py
core/render.py
core/sender.py
core/utils.py
core/parsers/__init__.py

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

---

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

当前仓库：Ishning/astrbot_plugin_parserURL
剩余触发次数：3