[Plugin] astrbot_plugin_HD2_daily_report

[MomijiOXO]

插件信息

{
  "name": "astrbot_plugin_HD2_daily_report",
  "display_name": "HD2银河快报",
  "desc": "通过启动自动化浏览器，定时抓取B站up银河快报动态中的图片并发送给指定群组。",
  "author": "椛椿",
  "repo": "https://github.com/MomijiOXO/astrbot_plugin_HD2_daily_report",
  "tags": [
    "游戏",
    "资讯",
    "vibe coding"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_HD2_daily_report

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

main.py

这是一份针对 main.py 的代码审查报告。该插件实现了定时抓取与手动查询功能，使用了 Playwright 进行网页自动化，整体逻辑较为连贯，但在架构设计与框架最佳实践上仍有改进空间。

1. 代码质量与编码规范

• 巨石类 (God Object) 倾向：BiliDailyReportPlugin 类承担了太多的职责（将近 800 行代码）。它不仅处理机器人事件响应，还包含了 APScheduler 定时任务调度、Playwright 浏览器生命周期管理、B 站 DOM 解析、本地文件缓存管理等逻辑。建议根据单一职责原则（SRP），将爬虫逻辑、持久化缓存管理抽离为单独的服务类。
• 全局拦截与基于 if-else 的路由设计：代码中使用了 @filter.event_message_type(filter.EventMessageType.ALL) 拦截了所有的消息事件，随后在 on_message 方法内使用繁杂的 if text == ... elif text == ... 进行分流。这是一种反模式，完全放弃了框架本身优秀的指令路由系统，也导致插件无法自动生成 Help 文档。建议将不同的命令拆分为独立的方法，并使用 @filter.command("命令名") 装饰器。

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

• 状态混用与并发竞态风险：在 scheduled_send、start_bili_qrcode_login 和手动触发逻辑中，同时依赖实例状态 self._pw, self._ctx 与局部变量 pw, ctx。如果用户在“定时任务”执行的过程中，同时发送了“今日快报”手动触发命令，两者都会调用 launch_persistent_browser()，导致上一个正在执行的浏览器上下文被强行关闭（_close_browser），从而引发各种不可预期的 Playwright Target Closed 错误。建议引入异步锁 (asyncio.Lock) 保护核心爬虫流程，避免重入。
• 底层 API 强耦合：在 _send_images_to_groups 方法中，为了规避某些发送限制，写了大量基于反射（getattr）的探测代码，试图挖掘底层的 call_action 发送 OneBot 协议的图片段。这种“黑魔法”绕过了 AstrBot 的标准抽象隔离层，一旦宿主框架内部属性重构或用户使用了非 OneBot 平台，此段逻辑将立刻崩溃。

3. 安全漏洞与最佳实践

• 安全的临时文件操作：在操作临时目录时，由于网络超时或下载异常退出，部分已下载的垃圾文件未能被确保清理。虽然有 clear_current_cache，但它仅在准备写入新的一期时调用。在复杂的生命周期中，建议结合清理脚本或 tempfile 模块规范化管理。
• CSS 强依赖脆弱性：对 B 站页面的 DOM 结构强依赖，如 .bili-dyn-item, .dyn-card-opus__pics 等硬编码的 CSS 选择器。前端页面一旦进行小幅重构，极易导致脚本瘫痪。可以将其提取为类常量以方便日后维护。

4. 可维护性与可读性

• 返回类型的缺失与模糊：缺少对复杂字典结果的数据结构定义。例如 parse_latest_report_from_page 返回一个嵌套字典，建议使用 TypedDict 或是 dataclasses 来清晰声明 matched_title, issue_code 等字段的类型，提高静态类型检查的覆盖度。

5. 潜在缺陷或问题

• 未经处理的浏览器异常：尽管使用了 try/except 包裹爬虫主要逻辑，但是在个别如 await page.title() 或 await page.query_selector() 的细粒度步骤中，如果遇到网络波动导致页面骤然 Crash 或上下文销毁，Playwright 会抛出特定的 Error (如 TargetClosedError)，这可能未被精细化捕获并妥善重试，导致机器人直接向管理员抛出难以理解的底层异常日志。
• 未配置时区的 APScheduler：虽然初始化了 AsyncIOScheduler，但并未显式设置时区。如果运行机器人的服务器系统时区设置不是北京时间（例如运行在海外 UTC 服务器上），09:00 的定时发送时间将会产生严重的偏移偏差。建议在初始化 Scheduler 时传入 timezone="Asia/Shanghai"。

---

代码评审团

人物一：Linus Torvalds
“你看过你自己的 on_message 函数吗？你挂载了一个监听所有消息的钩子，然后用一堆恶臭的 if-elif 字符串比较来决定执行什么代码？框架的设计者花了几个月写出了优雅的指令装饰器路由，而你却直接忽略了它们，退化到了上世纪 90 年代 CGI 脚本的写法！另外，把所有东西——从爬虫到浏览器调度再到文件 I/O——塞进一个将近 800 行的类里，你是打算给这个类建一个纪念碑吗？拆分你的代码，立刻！”

人物二：John Carmack
“在长时间运行的守护进程里管理无头浏览器，是一件需要极端注重稳健性的事。我注意到你在多处手动管理了浏览器的上下文，并且试图用 finally 来清扫它们。但由于你在类状态中保留了实例指针（self._pw），一旦发生了意外的并发触发（比如定时器和用户手动请求同时打过来），你的状态机就会陷入完全的混乱，进而导致僵尸进程堆积，吃光你服务器的内存。加上一把互斥锁（Mutex），让你的资源状态转移变得绝对确定吧。”

人物三：Tony Stark
“嘿，伙计，让你的 AI 助手每天早上去帮你买‘今日快报’这主意不错。但你的武器库太老旧了！你用一连串 getattr 的反射去深挖系统底层平台接口，只为了发一张图片？这就像是拆了钢铁战衣的反应堆去给微波炉供电！你应该跟框架现有的生态更紧密地握手，或者向框架维护者提交一个特性请求，而不是在这里写这么脆弱的 Hack 代码。此外，别太相信网站的前端工程师，明天他们改个 CSS 类名，你这套精准打击系统就只能对着空气输出了。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：MomijiOXO/astrbot_plugin_HD2_daily_report
剩余触发次数：4

[RC-CHN]

苏坡 earth, our home，，，

[astrbot-plugin-copybara]

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

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