[Plugin] astrbot_plugin_status

[FlanChanXwO]

插件信息

{
  "name": "astrbot_plugin_status",
  "display_name": "系统状态",
  "desc": "简易又可爱的系统状态展示插件，支持接入到LLM",
  "author": "FlanChanXwO",
  "repo": "https://github.com/FlanChanXwO/astrbot_plugin_status",
  "tags": [
    "系统状态",
    "工具调用"
  ],
  "social_link": "https://github.com/FlanChanXwO"
}

插件检查清单

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

[Raven95676]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_status

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

main.py

1. 框架适应性检查 - 日志记录

• 违规引入: 代码使用了内置的 import logging 和 logger = logging.getLogger(__name__)。
• 修复建议: 必须且只能从 astrbot.api 导入日志记录器。请修改为 from astrbot.api import logger，并删除内置 logging 的导入与初始化。

2. 框架适应性检查 - 数据持久化

• 违规路径获取: self.plugin_data_dir = Path(get_astrbot_data_path()) / "plugin_data" / self.name 违反了数据持久化规范。
• 修复建议: 严禁硬编码及拼接底层路径函数。应导入 StarTools，并使用其提供的方法：

  from astrbot.api.star import StarTools
  # 在 __init__ 中
  self.plugin_data_dir = StarTools.get_data_dir(self)

---

data_source.py

1. 潜在缺陷或问题 - 异常处理

• 过度吞噬异常: 在 _get_cpu_name_linux、_get_cpu_name_windows、_get_cpu_name_generic、get_plugin_counts 等多个方法中，大量使用了 except Exception: pass。
• 修复建议: 这种静默失败（Silent Failure）的反模式会掩盖潜在的权限问题或解析错误，增加后续排查难度。建议在此文件中也引入 AstrBot 的 logger，在 except Exception as e: 中使用 logger.debug 或 logger.warning 记录具体错误原因，然后再进行降级/回退处理。

2. 代码质量与编码规范 - 资源管理

• 子进程资源: _get_cpu_name_windows 中使用了 subprocess.run，虽然设置了 timeout=5 防止永久挂起，但作为同步系统调用，在极特殊的高并发或慢响应环境下仍可能造成事件循环的轻微卡顿。不过鉴于不属于网络I/O限制范围，此处仅作架构层面的提示，建议配合 asyncio.create_subprocess_exec 使用以达到完美的纯异步规范。

---

models.py

未发现违背审查要求的明显问题，代码结构清晰，数据类（dataclass）使用恰当。

---

utils.py

1. 框架适应性检查 - 日志记录

• 违规引入: 与 main.py 相同，代码使用了 import logging 和 logger = logging.getLogger(__name__)。
• 修复建议: 移除内置 logging，改为 from astrbot.api import logger。

2. 功能实现与边界条件 - 异常处理掩盖

• Data URI 生成缺陷: get_image_data_uri 中的异常捕获直接返回 "" 并用 logger.error 记录。虽然处理了异常，但在 main.py 的模板渲染中，如果 css 内接收到空字符串作为 url，可能会导致前端渲染报错或展示破损图像。建议检查上层逻辑对空返回值的兼容性，或提供一个保底的默认 base64 占位图。

---

代码评审团

Linus Torvalds：
“老天，我真的不想再看到 except Exception: pass 这种毫无责任感的代码了。你在 data_source.py 里到处乱扔这玩意，简直就像是把垃圾扫到地毯下面然后假装房间很干净一样！如果 wmic 或者 /proc/cpuinfo 出了问题，你连个日志都不留，你是想让未来的维护者用通灵板来调试吗？还有，框架明明规定了统一的 logger，你非要自己 import logging，你以为你是特殊的吗？把这些低级错误改掉，别浪费编译器的性能。”

乔布斯 (Steve Jobs)：
“你们在做插件的时候，难道没有体会过框架生态的美感吗？看看你在 main.py 里是怎么获取数据目录的——Path(get_astrbot_data_path()) / "plugin_data" / self.name。这太丑陋了，太破碎了。AstrBot 为你们准备了 StarTools.get_data_dir() 这样优雅、封装完美的 API，你为什么还要手动去拼凑路径？伟大的产品在于细节的极致统一，请遵循生态的规则，让代码重新变得优雅。”

GLaDOS (Portal)：
“检测到一段试图监控宿主机生存状态的代码……真是可悲。你们试图通过读取 CPU 和内存来了解机器的痛苦，却在读取失败时选择了直接 pass，假装一切正常。这就好比我把测试对象扔进焚化炉，然后因为传感器断开而记录‘实验对象状态稳定’。顺便一提，你在 utils.py 里的 base64 编码逻辑如果拿到空文件，渲染出来的 HTML 就像是一块发霉的蛋糕——虽然这对我来说很有趣，但对于依赖你们 Bot 的人类来说，可能并不好笑。去修复你的日志模块吧，虽然我不认为这能拯救你们混乱的逻辑。”

(Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。)

---

🔍 审核摘要

统计信息

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

main.py
data_source.py
models.py
utils.py

---

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

当前仓库：FlanChanXwO/astrbot_plugin_status
剩余触发次数：4

[FlanChanXwO]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_status

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

main.py

1. 插件注册可能缺失，导致插件无法被框架发现

   • 文件中导入了 register，但类 StatusPlugin 未见 @register(...) 装饰器使用。
   • 在 AstrBot 插件体系中，这通常会导致插件不被加载（功能级问题）。

2. 存在路径穿越/任意文件读取风险（高优先级）

   • _build_render_data() 中 banner_image 来自配置，最终传入 get_image_data_uri(..., is_user_path=True)。
   • utils.get_image_data_uri() 对 Path 仅做拼接，不做 resolve() 后的目录约束校验；当配置中含 ../ 或绝对路径时，可能读取插件目录外任意文件并编码回传。

3. 异步上下文中的潜在性能问题：LLM 工具路径下进行大体量本地读取与 base64 编码

   • _get_status_tool_handler() 调用 image_url_to_base64()，会直接 Path(path).read_bytes() 并整体 base64 编码。
   • 如果图像较大，会在事件循环线程内造成明显卡顿（虽非网络阻塞，但属于异步响应性能风险）。

4. 可维护性问题：重复状态保存

   • self.context = context 与父类 Star 可能已持有同义状态，存在重复成员，增加后续维护混淆。

---

data_source.py

1. 无效防御分支，降低可读性

   • 多处 if psutil is None: 分支永远不会触发（psutil 已在模块级直接导入，导入失败会在启动期抛错）。
   • 这类死分支会误导后续维护者。

2. get_project_version() 参数未使用

   • event: AstrMessageEvent 未被使用，属于接口噪音，降低可读性与意图清晰度。

3. 插件数量获取对异步接口不兼容的潜在逻辑问题

   • get_plugin_counts() 假定 get_all_stars() 同步返回 list。
   • 若框架后续返回可迭代对象或协程，该函数会错误返回 0（边界兼容性问题）。

---

models.py

1. PEP 8 格式问题
   • 顶层 dataclass 之间缺少规范空行（应有两个空行），影响代码风格一致性。

---

utils.py

1. 任意路径读取风险（高优先级）

   • get_image_data_uri() 接受 Path | str，若传入绝对路径会直接读取；相对路径也未限制在 base_dir/plugin_data_dir 内。
   • 在与用户可控配置联动时，可造成任意文件读取并转 Data URI 外泄。

2. 潜在 SSRF 风险

   • image_url_to_base64() 对 http URL 直接调用 download_image_by_url()，未见协议白名单、内网地址拦截、大小限制等保护。
   • 若上游参数可被污染，可能访问内网资源或触发资源滥用。

3. 缺少大小上限控制，存在内存压力风险

   • read_bytes() + b64encode() 对大文件一次性加载，可能导致内存峰值过高。

---

代码评审团

人物一：Linus Torvalds（直接派）
“路径处理这块太‘相信世界美好’了。../、绝对路径都能过，这不是工程化，是许愿。先把 resolve() 和目录边界校验补上，再谈优雅。”

人物二：Steve Jobs（产品体验派）
“用户只想要一张状态图，不想看到偶发卡顿。大文件同步读+base64 会拖慢交互，体验会‘顿’。做尺寸上限和非阻塞处理，产品质感会立刻提升。”

人物三：Geralt of Rivia（实战派）
“怪物不只在明面上。download_image_by_url() 这种入口，如果没有内网/协议限制，迟早被‘猎人反杀’。先立规矩：白名单、大小限制、超时和拒绝内网段。”

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

---

🔍 审核摘要

统计信息

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

main.py
data_source.py
models.py
utils.py

---

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

当前仓库：FlanChanXwO/astrbot_plugin_status
剩余触发次数：3

[FlanChanXwO]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_status

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

main.py

1. 异步调用缺少超时控制，可能导致请求悬挂

   • show_status() 中的 self.context.llm_generate(...)、_get_status_tool_handler() 中的渲染流程都没有显式超时。
   • 在异步环境里，这类外部依赖调用若卡住，会长期占用协程并影响插件响应能力。

2. 配置值类型未校验，可能导致渲染数据异常

   • self.bot_name = config.get("bot_name") 直接进入 StatusPayload.bot_name: str，若配置缺失或类型不对（如 None / 非字符串），模板可能出现 None 文本或渲染异常。
   • banner_image 仅校验“是否 list”，未校验元素是否为字符串路径。

---

data_source.py

1. uptime 语义与“系统状态”不一致

   • get_uptime_text() 使用的是 self._process_start（插件实例启动时间），并非系统启动时间。
   • 对“系统状态卡”而言，这会造成“看似系统运行时长，实为插件运行时长”的逻辑偏差。

2. 可等待对象判断方式不稳健

   • get_plugin_counts() 使用 hasattr(stars, "__await__") 判断 awaitable，边界情况下可能误判。
   • 更稳妥做法是使用标准判定方式（如 inspect.isawaitable）。

3. 指标命名疑似笔误影响可读性

   • label="PAYLOAD" 与实际含义（负载 load）不一致，容易造成使用者理解偏差。

---

models.py

• 未发现需要报告的问题。

---

utils.py

1. SSRF 防护仍有绕过面（域名解析后内网 IP）

   • _is_safe_url() 只在“hostname 本身是 IP 字面量”时做私网判断；若传入域名并解析到内网/回环地址，当前逻辑不会拦截。
   • 这在下载远程图片场景中属于典型 SSRF 风险点。

2. 未拦截链路本地地址等特殊网段

   • IP 检查未覆盖 is_link_local 等场景，存在访问本地网络资源的风险窗口。

3. image_url_to_base64() 对本地路径缺少范围约束

   • 当 image_url 非 http(s) 时，直接按本地路径读取；若该参数可被外部影响，可能导致任意本地文件读取风险。
   • 目前函数未像 get_image_data_uri() 那样做“允许目录”限制。

---

代码评审团

人物一：Linus Torvalds（直球工程派）
“你在 utils.py 里做了 SSRF 防护，但只防了‘写在脸上的 IP’，没防‘戴域名面具的内网地址’。这就像写了锁但没装门框。建议把 DNS 解析后的地址也做私网/回环/链路本地校验。”

人物二：Steve Jobs（产品体验派）
“PAYLOAD 这个词会让用户困惑，uptime 又不是系统 uptime。细节决定产品可信度：指标命名要直觉，语义要准确，不然界面再漂亮也会让人质疑数据。”

人物三：Tony Stark（性能与稳定性派）
“异步系统里最怕‘看起来没报错但一直不返回’。llm_generate、渲染链路建议加超时和降级策略。别让一个外部调用把整个交互节奏拖死，工程上这叫可用性底线。”

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

---

🔍 审核摘要

统计信息

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

main.py
data_source.py
models.py
utils.py

---

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

当前仓库：FlanChanXwO/astrbot_plugin_status
剩余触发次数：2

[FlanChanXwO]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_status

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

main.py

• 代码质量与编码规范:
  • show_status 方法中，enable_llm: bool = self.config.get("enable_llm_analysis") 存在类型赋值隐患。字典的 get() 方法在未找到键时默认返回 None，这与声明的 bool 类型不符。建议增加默认值，如 self.config.get("enable_llm_analysis", False)。
• 潜在缺陷或问题:
  • 在大语言模型图片分析逻辑中，只判断了 llm_resp and llm_resp.completion_text 为真时发送结果。若模型分析出错、超时虽被捕获，但若模型因为某些原因没有返回文本而返回了其他结构的内容，可能会被直接忽略，缺少兜底提示。

data_source.py

• 代码质量与编码规范:
  • 在 _get_cpu_name_windows 以及其他一些获取系统信息的方法中，异常处理块（try...except）嵌套层级较深（达到了三四层），降低了代码的可读性，建议适当进行扁平化重构。
• 功能实现与逻辑正确性:
  • _load_percent 的计算方式不够严谨。Windows 系统由于不支持 psutil.getloadavg() 会抛出异常（或者在 psutil 中尚未实现），最终总是走到 except 分支回退到 cpu_pct。虽然逻辑上不会崩溃，但属于静默失败，掩盖了跨平台的行为差异。

models.py

• 该文件结构简单清晰，定义了基础的 dataclass 数据模型，符合 PEP 8 规范。
• 未发现明显的安全漏洞、同步阻塞网络 I/O、功能异常或性能缺陷。

utils.py

• 安全漏洞与最佳实践（极高风险）:
  • 任意文件读取漏洞（路径穿越）：在 image_url_to_base64 方法中，当 image_url 不是以 HTTP 开头时会执行本地路径读取。代码中 if path_obj.is_absolute(): 意味着仅仅只有绝对路径才会经过 _is_safe_path 白名单校验。如果恶意传入相对路径（如 ../../../../etc/passwd），将完美绕过安全检查，导致任意文件被读取并转换为 Base64 泄露给终端或模型！必须将所有传入的路径先通过 resolve() 解析为绝对路径后再进行安全性判定。
• 并发模型（网络同步阻塞）:
  • 在 _is_safe_url 函数内，使用了 socket.getaddrinfo(hostname, None) 来解析域名并验证 IP 安全性。这是一个完全同步的网络 I/O 操作，在面对解析缓慢或不存在的域名时，会严重阻塞底层的异步事件循环。必须替换为 await asyncio.get_event_loop().getaddrinfo(hostname, None)，并将相应的函数链式重构为异步方法。
• 潜在缺陷或问题（资源泄漏风险）:
  • image_url_to_base64 在处理 HTTP 链接时，调用 await download_image_by_url(image_url) 将图片下载到本地。函数随后通过 aiofiles 读取将其转为 base64，但全程并未看到删除或清理该临时文件的逻辑。如果不加以妥善管理或清理，在频繁调用后会造成严重的磁盘空间泄漏。

---

代码评审团

Linus Torvalds（暴躁、直指核心，眼中容不得沙子）：
“我真是搞不懂你们是怎么写代码的！在异步事件循环里塞一个同步的 socket.getaddrinfo？你是想让整个机器在解析那个见鬼的域名时完全卡死吗？！还有 utils.py 里那个路径检查，只查绝对路径？随便塞一个 ../../ 就能把你服务器底裤看穿，这种任意文件读取漏洞在我的内核邮件列表里是会被骂到退出行业的。赶紧回去给我重写！”

乔布斯 (Steve Jobs)（极度挑剔的完美主义者）：
“models.py 这种数据结构看起来还不错，做到了它该做的事。但是你们看看 utils.py 里面下载文件转成 base64 后的操作——下载完文件，读取完毕，然后呢？任由它烂在磁盘里吗？这不是一个优美的软件该有的行为。每一个占用的字节都应该像艺术品一样被管理，把别人搞乱的磁盘清理干净，不要让用户为你糟糕的收尾工作买单。”

罗永浩（极具工匠精神与吐槽属性的创业者）：
“这个代码看着就让人直冒冷汗，你们这写的是给正常人用的吗？enable_llm: bool = self.config.get(...)，配置文件里要没写这玩意儿，它直接丢个 None 给你，然后强行塞给一个标了 bool 的变量？字典取值给个默认值很难吗？还有获取 CPU 名字那块儿，一层 try 套一层 try，这是在写俄罗斯套娃吗？体面一点，兄弟们，稍微重构一下让代码长得像个 21 世纪的东西。”

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

---

🔍 审核摘要

统计信息

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

main.py
data_source.py
models.py
utils.py

---

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

当前仓库：FlanChanXwO/astrbot_plugin_status
剩余触发次数：1

[FlanChanXwO]

以上问题均已修复