[Plugin] astrbot_plugin_zirunbi

[oyxning]

插件信息

{
  "name": "astrbot_plugin_zirunbi",
  "display_name": "孜然币模拟炒股",
  "desc": "一款多币种虚拟加密货币交易模拟插件。在群聊中体验模拟炒股的乐趣，体验“韭菜”的起起落落！",
  "author": "LumineStory",
  "repo": "https://github.com/oyxning/astrbot_plugin_zirunbi",
  "tags": [
    "炒股",
    "模拟",
    "本地"
  ],
  "social_link": "https://github.com/oyxning"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_zirunbi

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

main.py

代码质量与编码规范:

• 异常处理导入: 文件开头使用 try...except ImportError 来处理本地模块导入（from .database vs from database）。虽然这在开发环境中常见，但在生产级插件中，建议统一包结构，保持导入的一致性，以提高代码整洁度。
• 管理权限逻辑: is_admin 定义在 zrb 方法内部。虽然可行，但如果未来有其他指令需要权限检查，会导致代码重复。建议将其提取为类的一个私有方法 self._is_admin(user_id)。

数据持久化:

• 硬编码路径 (严重): self.db_path = f"sqlite:///{os.path.join(os.path.dirname(__file__), 'zirunbi.db')}" 违反了 AstrBot 的数据持久化规范。插件不应直接在源代码目录下存储数据文件，这会导致更新插件时数据丢失或权限问题。
  • 建议: 必须从 astrbot.api.star 导入 StarTools，并使用 StarTools.get_data_dir("zrb_trader") 获取标准数据目录。确保先创建该目录（如果不存在），再拼接数据库文件名。

database.py

安全漏洞与最佳实践:

• 同步网络 I/O (严重): import requests 及其在 sync_network_time 中的使用 requests.head(...) 是同步阻塞操作。虽然此函数目前在 market.py 的线程中或初始化时调用，但在异步框架中引入同步网络库是极大的隐患。如果在主线程（如模块导入或初始化阶段）调用它，会阻塞整个 AstrBot 的事件循环，导致机器人在请求超时期间（3秒）无响应。
  • 建议: 使用 aiohttp 或其他异步网络库，或者完全移除对外部网络的依赖（直接使用服务器系统时间通常足够，除非对时间精度有极高要求）。

框架适应性检查:

• 日志记录: 使用了 print(f"[Zirunbi] ...")。违反了框架适应性要求。
  • 建议: 必须使用 from astrbot.api import logger 并使用 logger.info() 或 logger.error()。

market.py

并发模型:

• 阻塞初始化: __init__ 方法中调用了 sync_network_time()。Market 类在 ZRBTrader.__init__ 中被实例化，这意味着插件加载时会执行同步网络请求。如果网络不通或延迟，会直接卡死 Bot 的启动过程。
• 线程使用: 使用 threading.Thread 来运行市场循环是可行的，但在异步框架中，更推荐使用 asyncio.create_task 配合 async def _loop 和 await asyncio.sleep。这将减少线程上下文切换的开销，并使数据库操作更容易与主线程的异步环境集成（如果切换到异步DB驱动）。

框架适应性检查:

• 日志记录: 多处使用了 print(...)（例如 print(f"[Zirunbi] Market state...")）。违反了日志记录要求。
  • 建议: 全部替换为 astrbot.api.logger。

代码质量:

• 锁的粒度: 虽然使用了 threading.Lock，但在 _update_prices 和 match_orders 之间，数据库会话 (session) 的创建和提交在锁外或锁内混合使用。SQLite 在多线程模式下需要小心配置 check_same_thread=False，或者依赖 SQLAlchemy 的连接池。目前的实现中，Market 线程和 ZRBTrader 主线程（通过 match_single_order）都会访问数据库，存在潜在的竞争条件风险。

plotter.py

潜在缺陷或问题:

• 线程安全与全局状态 (严重): matplotlib.pyplot (作为 plt) 是一个基于状态机的接口，维护全局状态。
  • plot_holdings_multi 中使用了 plt.switch_backend('Agg')，plt.subplots()，plt.title() 等。
  • 如果两个用户几乎同时触发绘图指令，或者绘图操作与后台线程发生冲突，全局状态可能会混乱（例如，标题被覆盖，图表内容混合，或者抛出异常）。
  • 此外，plt.switch_backend 应该在模块级别设置一次，而不是在每次函数调用时设置。
  • 建议: 完全放弃 pyplot 状态机接口。使用面向对象的方式：from matplotlib.figure import Figure，直接实例化 fig = Figure()，然后 ax = fig.add_subplot(111)。对于 mplfinance，确保它不修改全局 pyplot 后端，或者加锁保护绘图代码块。

框架适应性检查:

• 日志记录: print(f"Plot error: {e}") 违反了日志记录要求。

---

代码评审团

人物一：Linus Torvalds
“我在 database.py 里看到了什么？import requests？在一个异步框架里？你是不是想让整个程序因为一个百度的连接超时而彻底挂起？这简直是谋杀性能。还有那个 sync_network_time，在一个聊天机器人插件里同步网络时间？你的服务器时间是有多不准？如果服务器时间坏了，那是运维的问题，不是你写一个阻塞整个线程的丑陋补丁的理由。把那些 print 语句给我删了，学会用 logger，别像个业余爱好者一样往 stdout 吐垃圾。”

人物二：Steve Jobs
“我看不到这个插件的‘灵魂’，只能看到混乱。main.py 里那个数据库路径... os.path.join(os.path.dirname(__file__)...，这太丑陋了。你把用户的珍贵数据直接扔在代码文件夹里？这不仅是不安全，这是对用户体验的漠视。当他们更新插件时，所有的数据瞬间消失，就像从来没存在过一样。我们要给用户一个安稳的家（StarTools.get_data_dir），而不是让他们睡在代码仓库的地板上。还有 plotter.py，那是灾难。你在全局状态下画图？优雅的代码应该是独立的、无副作用的。重写它。”

人物三：GLaDOS (Portal)
“噢，这真是太令人感动了。你在试图模拟一个股市，结果你甚至无法正确模拟一个非阻塞的 I/O 操作。在 market.py 里启动一个线程来跑循环？虽然不算完全错误，但看起来就像是用土豆来给超级计算机供电一样原始。最精彩的是 plotter.py，你居然在多线程环境下使用 pyplot 的全局接口。我迫不及待地想看看，当两个测试对象同时查询资产时，他们的饼图混合在一起会产生什么样美妙的科学火花。也许你会创造出一种新的金融衍生品：‘薛定谔的持仓’。继续保持，为了科学。”

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
database.py
market.py
plotter.py

---

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

[astrbot-plugin-copybara]

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

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