[Plugin] astrbot_plugin_gok

[qsc20001102]

插件信息

{
  "name": "astrbot_plugin_gok",
  "display_name": "王者荣耀游戏数据查询工具",
  "desc": "王者荣耀的战绩、资料等内容的查询",
  "author": "飞翔大野猪",
  "repo": "https://github.com/qsc20001102/astrbot_plugin_gok",
  "tags": [
    "王者荣耀",
    "数据查询"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_gok

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

Python 代码审查报告

综合评审总结

经过全面审查,该项目在大部分方面表现良好,代码结构清晰,异步处理规范。但仍发现若干需要改进的问题,主要集中在错误处理、类型安全、资源管理和编码规范方面。

---

main.py

发现的问题:

1. 框架适应性 - 未调用 html_render 方法

• 位置: GOKCommands.T2I_image_msg() 方法第 105 行
• 问题: 代码中调用了 self.html_render(data["temp"], data["data"], options={}),但 GOKCommands 类没有继承或实现 html_render 方法
• 建议: 应从 Star 基类继承该方法,或通过依赖注入的方式传入渲染器

2. 代码质量 - 类型注解缺失

• 位置: 多处函数参数缺少类型注解
• 问题: parse_message 返回类型使用了 list[str] | None,但参数和内部变量缺少注解
• 建议: 为提高可维护性,建议添加完整的类型注解

3. 潜在缺陷 - 异常处理不够细致

• 位置: _call_with_auto_args 方法
• 问题: 使用了宽泛的 except Exception,可能掩盖具体错误
• 建议: 区分不同类型的异常,提供更精确的错误信息

4. 逻辑正确性 - 参数转换异常处理

• 位置: _call_with_auto_args 方法第 68-73 行

try:
    if p.annotation is int:
        call_args.append(int(raw))
    elif p.annotation is float:
        call_args.append(float(raw))
    else:
        call_args.append(raw)
except Exception:
    call_args.append(p.default)

• 问题: 当转换失败且参数没有默认值时,会导致逻辑错误
• 建议: 应在 except 块中检查 p.default 是否存在,不存在时抛出明确的异常

5. 可维护性 - 资源清理不完整

• 位置: terminate 方法
• 问题: 对 self.gokmag 没有进行清理
• 建议: 添加 self.gokmag = None 以确保资源完全释放

---

core/fun_basic.py

发现的问题:

1. 代码质量 - 使用 print 而非 logger

• 位置: 第 23 行

print(f"提取字段时出错: {e}")

• 问题: 违反了框架的日志记录规范
• 建议: 应该导入并使用 from astrbot.api import logger,然后调用 logger.error()

2. 安全性 - 异常信息泄露

• 位置: extract_fields 函数
• 问题: 直接打印异常可能泄露敏感信息
• 建议: 使用日志系统记录,并考虑是否需要向用户返回详细错误

3. 功能实现 - 返回空列表而非 None

• 位置: extract_fields 函数返回值
• 问题: 出错时返回空列表可能导致调用方误认为"没有数据"而非"处理出错"
• 建议: 考虑抛出异常或返回 None,让调用方明确知道发生了错误

---

core/gok_commands.py

发现的问题:

1. 架构问题 - 不应继承 Star

• 位置: 类定义 class GOKCommands(Star)
• 问题: GOKCommands 作为业务逻辑层,不应继承框架的 Star 类
• 建议: 移除继承,改为普通类,通过依赖注入获取所需的框架能力

2. 未实现的方法 - html_render

• 位置: T2I_image_msg 方法第 27 行

url = await self.html_render(data["temp"], data["data"], options={})

• 问题: 代码调用了 self.html_render(),但该类未定义此方法,且继承的 Star 类也未提供
• 建议: 需要明确如何获取 html_render 方法,可能需要通过构造函数注入

3. 代码质量 - 参数类型注解不一致

• 位置: 多处方法参数
• 问题: gok_zhanji 中 option 参数应为 int 而非 str
• 建议: 统一参数类型定义

4. 潜在缺陷 - 重复的异常处理逻辑

• 位置: 三个 *_msg 方法
• 问题: 相同的 try-except 逻辑重复出现
• 建议: 可以使用装饰器或提取公共方法来减少重复代码

---

core/gok_data.py

发现的问题:

1. 代码质量 - 类型转换逻辑复杂

• 位置: get_gokid 方法

try:
    int(name)
    if int(name) >=100000000:
        gokid = name
        return gokid
    else:
        raise Exception("输入不是ID")
except (ValueError, TypeError, Exception):

• 问题:
  1. int(name) 调用了两次,浪费性能
  2. 捕获了自己抛出的 Exception,逻辑混乱
  3. 判断逻辑可以更清晰
• 建议: 重构如下:

try:
    id_value = int(name)
    if id_value >= 100000000:
        return str(id_value)
    # 如果是小于阈值的数字,当作名称处理
except (ValueError, TypeError):
    pass
# 按名称查询数据库...

2. 安全性 - SQL 注入风险

• 位置: select 方法
• 问题: 虽然使用了参数化查询,但 like 变量的构造方式可能引入风险
• 建议: 当前实现是安全的,但建议添加注释说明已考虑安全性

3. 功能实现 - 错误的异常处理

• 位置: 多处 except FileNotFoundError
• 问题: 数据库操作不会抛出 FileNotFoundError,这个异常捕获毫无意义
• 建议: 应该捕获 aiosqlite.Error 或相关的数据库异常

4. 潜在缺陷 - 未处理空 token

• 位置: __init__ 方法
• 问题: 虽然记录了日志,但没有阻止后续使用空 token 调用 API
• 建议: 考虑在初始化时如果 token 为空,是否应该抛出异常或设置标志位

5. 代码质量 - 重复的模板加载错误处理

• 位置: 多处 except FileNotFoundError 加载模板
• 问题: 相同的错误处理逻辑重复多次
• 建议: 提取为私有方法 async def _load_template_safe()

---

core/request.py

发现的问题:

1. 潜在缺陷 - Session 单例模式的线程安全问题

• 位置: get_session 方法

if self._session is None or self._session.closed:
    timeout = ClientTimeout(total=self.base_timeout)
    self._session = ClientSession(timeout=timeout)

• 问题: 在高并发场景下,多个协程可能同时检测到 _session is None,导致创建多个 Session
• 建议: 使用 asyncio.Lock 保护 Session 的创建:

if self._lock is None:
    self._lock = asyncio.Lock()
async with self._lock:
    if self._session is None or self._session.closed:
        # 创建 session

2. 功能实现 - JSON 解析逻辑冗余

• 位置: _handle_response 方法第 56-65 行

try:
    data = await response.json()
except Exception:
    text = await response.text()
    try:
        loop = asyncio.get_running_loop()
        data = await loop.run_in_executor(None, json.loads, text)

• 问题:
  1. response.json() 本身已经处理了 JSON 解析,不需要再用 run_in_executor
  2. 使用线程池解析 JSON 是不必要的开销
• 建议: 简化为:

try:
    data = await response.json()
except Exception:
    text = await response.text()
    try:
        data = json.loads(text)
    except json.JSONDecodeError:
        logger.error(...)
        return None

3. 代码质量 - 业务逻辑验证过于宽松

• 位置: _validate_api_payload 方法

if code not in [200, "0", 0, 1]:

• 问题: 允许多种代码格式可能导致不一致
• 建议: 统一 API 返回格式,只接受一种类型的成功码

4. 安全性 - 响应内容截断可能不足

• 位置: 日志输出

logger.error(f"无法解析响应为 JSON。原始内容: {text[:100]}...")

• 问题: 只截取前 100 个字符可能在某些情况下仍然包含敏感信息
• 建议: 考虑完全不输出原始内容,或使用更安全的摘要方式

---

core/sqlite.py

发现的问题:

1. 安全性 - SQL 注入风险

• 位置: 多个方法中的表名拼接

sql = f"INSERT INTO {table} ({keys}) VALUES ({placeholders})"
sql = f"UPDATE {table} SET {set_clause} WHERE {where}"
sql = f"DELETE FROM {table} WHERE {where}"

• 问题: 直接拼接表名和 WHERE 子句,如果这些参数来自用户输入,存在 SQL 注入风险
• 建议:
  1. 对表名进行白名单验证
  2. 在文档中明确说明 table 和 where 参数不应直接来自用户输入
  3. 考虑使用更安全的查询构建器

2. 潜在缺陷 - 资源泄漏风险

• 位置: execute 方法

async def execute(self, sql: str, params: Tuple = ()):
    async with self.conn.execute(sql, params):
        await self.conn.commit()

• 问题: async with 块中没有使用游标,可能导致资源未正确释放
• 建议: 明确使用游标:

async def execute(self, sql: str, params: Tuple = ()):
    async with self.conn.execute(sql, params) as cursor:
        await self.conn.commit()

3. 功能实现 - 连接状态检查缺失

• 位置: 所有数据库操作方法
• 问题: 没有检查 self.conn 是否已连接,如果在 connect() 前调用会抛出 AttributeError
• 建议: 在方法开始处添加检查:

if not self.conn:
    raise RuntimeError("Database not connected. Call connect() first.")

4. 可维护性 - 缺少上下文管理器

• 位置: 整个类
• 问题: 虽然提供了 connect() 和 close() 方法,但没有实现 __aenter__ 和 __aexit__
• 建议: 实现异步上下文管理器以支持 async with 语法:

async def __aenter__(self):
    await self.connect()
    return self

async def __aexit__(self, exc_type, exc_val, exc_tb):
    await self.close()

---

代码评审团

Linus Torvalds:
"你们的异常处理简直是一团糟!到处都是 except Exception,这跟没写有什么区别?还有那个 FileNotFoundError 捕获数据库操作的代码,这是哪个天才写的?数据库操作什么时候会抛文件未找到异常了?去读读文档再来写代码!不过,我必须承认,异步处理部分做得还算干净,至少没有到处用 time.sleep() 这种蠢事。Session 复用也做对了,只是线程安全问题需要修复。记住:好的代码是能让维护者一眼看懂的代码,而不是埋一堆坑让后来者踩!"

Grace Hopper:
"我看到了一些很有前景的架构设计,比如分层清晰的业务逻辑和数据访问层。但是,孩子们,细节决定成败!你们的类型注解做得很不一致,有些地方很详细,有些地方完全缺失。这就像写说明书只写了一半——读者会困惑的。还有那个 GOKCommands 类继承 Star 的设计,这违反了单一职责原则。一个类应该只有一个改变的理由,而你现在给了它两个:业务逻辑变化和框架接口变化。建议重新审视你的类层次结构,使用组合而非继承。记住我说过的话:最危险的短语是'我们一直都这么做'。"

Douglas Crockford:
"让我们谈谈你的 JSON 处理。在 request.py 中,你试图在 JSON 解析失败时用线程池再解析一次——这是过度工程化的典型案例。response.json() 已经是异步的了,不需要画蛇添足。还有你的 API 响应验证,接受 [200, "0", 0, 1] 四种不同的成功码?这种不一致性会成为未来的噩梦。统一你的数据格式!另外,SQL 拼接问题需要立即修复,这可不是闹着玩的。不过我很欣赏你对异步模式的理解,aiohttp 的使用基本正确,只是 Session 管理需要加锁。继续保持这种对异步最佳实践的追求,但同时也要注重一致性和安全性。"

---

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

---

🔍 审核摘要

统计信息

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

main.py
core/__init__.py
core/fun_basic.py
core/gok_commands.py
core/gok_data.py
core/request.py
core/sqlite.py

---

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