[Plugin] astrbot_plugin_qzone_ultra

[diaomin66]

插件信息

{
  "name": "astrbot_plugin_qzone_ultra",
  "display_name": "QQ空间Ultra",
  "desc": "QQ空间Ultra，更稳定的QQ空间插件，支持自动绑定QQ空间，采用独立进程：占用极低、稳定性极高，支持看/评/赞/发/写/删说说、回评、投稿审核、自动发评和 LLM tools。",
  "author": "雪碧bir",
  "repo": "https://github.com/diaomin66/astrbot_plugin_qzone_ultra",
  "tags": ["QQ空间"],
  "social_link": ""
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_qzone_ultra

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

main.py

• 数据持久化: 插件初始化时通过 self.data_dir = self.root / "data" / "qzone" 硬编码了数据存储路径，违反了框架的数据持久化规范。应从 astrbot.api.star 导入 StarTools，并使用 StarTools.get_data_dir() 来动态获取规范的数据存储目录。

qzone_bridge/client.py

• 框架适应性/日志记录: 代码顶部使用了 Python 内置的 logging 模块（import logging 与 log = logging.getLogger(__name__)），违反了“必须且只能从 astrbot.api 导入 logger”的严苛规定。

qzone_bridge/controller.py

• 框架适应性/日志记录: 使用了 Python 内置的 logging 模块，违反了只允许使用 astrbot.api.logger 的规范。
• 并发模型/同步阻塞: _port_is_free 方法中使用了同步网络操作（sock.bind(("127.0.0.1", int(port)))）来进行端口探测，且该方法在异步函数 ensure_running 内被直接同步循环调用（最多 32 次）。虽然本地端口绑定极快，但从原理上仍属于同步阻塞网络 I/O，存在阻碍事件循环的风险。建议将此调用包在 asyncio.to_thread 中，或改用原生的 asyncio.start_server 尝试非阻塞监听。

qzone_bridge/daemon.py

• 框架适应性/日志记录: 文件内同样使用了 Python 内置的 logging 模块。虽然该文件设计有独立运行模式，但作为插件的一部分被引用时，仍然需要严格遵守框架日志规范，必须替换为 astrbot.api.logger（在独立运行时可通过捕获异常作容错）。

qzone_bridge/post_service.py

• 框架适应性/日志记录: 顶部引入并使用了 Python 内置的 logging 模块，违反了日志记录相关要求。

---

代码评审团

Linus Torvalds：
你在 controller.py 里搞的那个端口扫描循环（_port_is_free）简直让我血压都上来了。在异步的事件循环里跑一堆同步的 socket 绑定？你是嫌系统的事件循环太闲，想给它放个假吗？别跟我说本地端口绑定很快不会出问题，把网络 I/O 规规矩矩地扔进线程池里，或者直接用 asyncio 提供的非阻塞接口去试探，千万不要在异步的主干道上玩火！

乔布斯：
我们对完美架构的追求不仅体现在运行效率，也体现在代码融入生态的姿态。你看 main.py 里的那个数据存储路径 self.root / "data" / "qzone"，它显得如此的突兀和不和谐。它拒绝融入系统为你准备好的底层设施。你应该拥抱 StarTools.get_data_dir()，让数据优雅地待在它本该存在的地方。一件伟大的艺术品绝不容忍这样的硬编码妥协。

罗永浩：
我翻了翻你这几个子目录下的文件，满篇的 import logging。哎呀，这就太不体面了朋友。人家 AstrBot 框架明明给你准备好了统一规范的 logger，你偏不用，非要各自为政去整原生的 logging。你这是缺乏对框架基础规范的敬畏心啊。作为有工匠精神的开发者，咱们能不能把日志调用的姿势统一一下，别让代码显得那么随意，好吗？

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

---

🔍 审核摘要

统计信息

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

daemon_main.py
main.py
qzone_bridge/__init__.py
qzone_bridge/client.py
qzone_bridge/controller.py
qzone_bridge/daemon.py
qzone_bridge/drafts.py
qzone_bridge/errors.py
qzone_bridge/json_store.py
qzone_bridge/llm.py
qzone_bridge/media.py
qzone_bridge/models.py
qzone_bridge/onebot_cookie.py
qzone_bridge/parser.py
qzone_bridge/post_service.py

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

---

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

当前仓库：diaomin66/astrbot_plugin_qzone_ultra
剩余触发次数：4

[diaomin66]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_qzone_ultra

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

main.py

• 功能实现与逻辑正确性：

  • 缺失的 event 参数：根据框架要求，除 on_astrbot_loaded 外，所有使用 @filter 装饰的事件监听器方法其签名中必须包含 event 参数。但在代码中，@filter.command_group("qzone") def qzone(self): 和 @filter.on_platform_loaded() async def qzone_on_platform_loaded(self): 均遗漏了 event: AstrMessageEvent 参数。这在框架层级可能会导致事件路由和调用时发生参数不匹配的异常。

• 潜在缺陷或问题：

  • 粗暴的环境注入与重载 (_prepare_local_qzone_bridge_imports)：代码在头部使用 sys.path[:] = ... 和 sys.modules.pop(name, None) 进行热重载和缓存清理。这种强制篡改 Python 进程全局状态的行为极具侵入性，在包含多个插件的生产环境（特别是异步应用和常驻内存的机器人）中，非常容易引发与其他共享相似依赖树插件之间的冲突或不可预知的状态污染。

qzone_bridge/astrbot_logging.py

• 框架适应性检查（严重）：
  • 违规使用内置 logging 模块：代码中直接出现了 import logging 并且试图使用 logging.getLogger(name) 与 logging.basicConfig 作为 fallback。这严重违反了要求中的**“严禁使用任何其他第三方日志库或 Python 内置的 logging 模块”**。尽管您的初衷是为了兼容 Standalone daemon 环境的单独运行，但此类设计侵犯了框架的强限制。建议在 daemon 入口和插件入口通过“依赖注入”来传递对应的 logger 实例，保持底层模块的纯粹，坚决移除直接的 import logging 导入。

---

代码评审团

人物一：Linus Torvalds
"Look at this absolute garbage in _prepare_local_qzone_bridge_imports! 你到底在干什么？强行清空 sys.modules 还要操作 sys.path 就为了热重载？这是什么蹩脚的黑客玩具？不要再试图把解释器的全局状态当成你家后院的垃圾桶一样乱翻了！如果不赶紧用规范的依赖管理或者环境隔离来解决这问题，迟早别人写的代码也会因为你这愚蠢的侧漏操作而崩溃离场！"

人物二：史蒂夫·乔布斯 (Steve Jobs)
"我们一直追求的是一种浑然天成的设计，一种对极致的执着。而不是在 astrbot_logging.py 里偷偷摸摸地塞进去一个 import logging 做低劣的 fallback！我们定下的规矩是唯一的 astrbot.api，你却在破坏这种纯粹的美感和一致性。如果你要兼容两个世界，请去用优雅的依赖注入。细节，永远是细节！把妥协的产物从代码中拿掉！"

人物三：死侍 (Deadpool)
"嘿！对面的老兄，我们都知道你在写 qzone() 和 qzone_on_platform_loaded() 的时候把 event 参数丢到九霄云外去了！系统规则明明白白地在第四面墙上写着：除了那个破例的哥们，谁出门挨 @filter 装饰都得老老实实带上 event 护照！别再装作没看见了，赶紧给它们加上，不然等框架一运行，你的代码就会像休叔的紧身衣一样当场裂开！"

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

---

🔍 审核摘要

统计信息

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

daemon_main.py
main.py
qzone_bridge/__init__.py
qzone_bridge/astrbot_logging.py
qzone_bridge/client.py
qzone_bridge/controller.py
qzone_bridge/daemon.py
qzone_bridge/drafts.py
qzone_bridge/errors.py
qzone_bridge/json_store.py
qzone_bridge/llm.py
qzone_bridge/media.py
qzone_bridge/models.py
qzone_bridge/onebot_cookie.py
qzone_bridge/parser.py

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

---

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

当前仓库：diaomin66/astrbot_plugin_qzone_ultra
剩余触发次数：3

[diaomin66]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_qzone_ultra

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

main.py

• 代码质量与编码规范:

  • _prepare_local_qzone_bridge_imports() 方法中通过修改 sys.path 并在运行时暴力删除 sys.modules 中的缓存来强制热重载模块。这种黑魔法做法在复杂的异步环境中非常危险，极易引发难以预料的模块状态不一致或悬挂引用问题，降低了代码的稳定性和可预测性。

• 框架适应性检查 (针对 main.py 的额外要求):

  • 通用事件监听器签名违规：在 qzone_on_platform_loaded 方法上使用了 @filter.on_platform_loaded() 装饰器，但其签名 async def qzone_on_platform_loaded(self): 中缺少了必需的 event 参数。根据规范，除去 on_astrbot_loaded 外，所有使用 @filter 装饰的事件监听器方法都必须包含 event 参数（或建议直接改用 on_astrbot_loaded 来执行初始化逻辑）。

qzone_bridge/astrbot_logging.py

• 框架适应性检查:
  • 严重的日志记录违规：代码中导入了 Python 内置的 logging 模块（import logging），并使用了 logging.getLogger(name) 和 logging.basicConfig(...)。这明确且直接地违反了框架检查要求中 “严禁使用任何其他第三方日志库或 Python 内置的 logging 模块” 的规定。即使是为了兼顾 standalone daemon 独立运行环境的兼容性，在当前上下文审查标准下也是不允许的。必须重构代码以确保所有日志仅通过 from astrbot.api import logger 来接管。

qzone_bridge/controller.py

• 并发模型与潜在缺陷:
  • _run_quiet 函数使用了同步的 subprocess.run。而在 _port_owner_pids、_pid_command_line 等函数中被反复调用，执行操作系统级别的子进程命令（如 netstat, lsof, taskkill 等）。当这个 Controller 运行在异步事件循环中时，这些底层阻塞的子进程调用会直接卡住当前线程，导致整个异步应用（包括机器人的所有其他响应）出现阻塞。应使用 asyncio.create_subprocess_exec 或把它们放入 asyncio.to_thread 线程池中执行。

qzone_bridge/json_store.py

• 潜在缺陷或问题:
  • 文件中全局及类级别加锁仅使用了同步的 threading.RLock，虽然当前大部分读写行为都是快速的本地文件 I/O，但在全异步的应用框架下，如果有多个协程 (Coroutine) 跨越网络或复杂逻辑访问同一个 AtomicItemStoreFile 实例，由于 RLock 会阻塞系统线程而不是挂起协程，这存在导致死锁或降低事件循环并发效率的潜在隐患，推荐将其替换或辅以 asyncio.Lock。

代码评审团

人物一：Linus Torvalds：
看在上帝的份上，你在 main.py 里面的 _prepare_local_qzone_bridge_imports 写的是什么鬼东西？在运行时手动去把 sys.modules 里的模块弹出来？你以为你是在给内核打热补丁吗？！在解释型语言里搞这种暴力的模块清理，你迟早会遇到那种调试三天三夜都找不到原因的内存泄漏和虚假类型。老老实实管理好你的 import 路径，别给以后的维护者埋地雷！

人物二：乔布斯 (Steve Jobs)：
这代码太缺乏“禅意”了。在 astrbot_logging.py 里，我看到你用了一堆丑陋的 try-except 去妥协，竟然还引回了那个过时的内置 logging 模块。用户根本不在乎你所谓的“独立进程兼容性”，我要的是生态的完美统一！既然制定了 AstrBot 的规范，就应该狠下心把这些不和谐的杂质全部删掉，你这样做完全不够极简。

人物三：强尼·银手 (Johnny Silverhand)：
老兄，你在这个 controller.py 里直接调 subprocess.run 去跑 netstat 和 taskkill？你这是想把整个异步赛博空间拉回到拨号上网时代吗？这种粗暴的系统调用会直接把你的事件循环死死卡住！赶紧给我把它们全换成 asyncio.create_subprocess_exec 跑在子进程里，别给那些破烂系统环境留下卡死机器人的后门！醒醒吧，现在可是异步时代！

---

🔍 审核摘要

统计信息

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

daemon_main.py
main.py
qzone_bridge/__init__.py
qzone_bridge/astrbot_logging.py
qzone_bridge/client.py
qzone_bridge/controller.py
qzone_bridge/daemon.py
qzone_bridge/drafts.py
qzone_bridge/errors.py
qzone_bridge/json_store.py
qzone_bridge/llm.py
qzone_bridge/media.py
qzone_bridge/models.py
qzone_bridge/onebot_cookie.py
qzone_bridge/parser.py

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

---

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

当前仓库：diaomin66/astrbot_plugin_qzone_ultra
剩余触发次数：2

[diaomin66]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_qzone_ultra

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

qzone_bridge/astrbot_logging.py

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

• 违规：该文件试图实现一个 _StandaloneLogger 以在不同环境中动态回退，并在文件末尾通过 logger = get_logger("qzone_bridge") 导出。这严重违反了“日志记录器 logger 必须且只能从 astrbot.api 导入，严禁使用任何其他第三方日志库或内置模块”的严格规范。这导致其他模块导入并使用的是私有封装的 Logger，而非框架原生的 Logger。
• 建议：彻底移除此自定义日志兼容层。所有需要打印日志的模块，必须直接在其头部写入 from astrbot.api import logger。

---

qzone_bridge/client.py

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

• 违规：文件顶部使用了 from .astrbot_logging import get_logger; log = get_logger(__name__)，违反了必须直接从 astrbot.api 导入的严格规定。

代码质量与编码规范：

• 过于复杂的代码块：_request_text 方法长达百行以上。该方法内部混合了网络重试循环、各类状态码判断、基于规则的 301/302 重定向跟随拦截逻辑、以及异常处理转换等。最大嵌套层级达到了 6 层，极大地增加了阅读和维护成本。
• 建议：建议将 if response.status_code in QZONE_REDIRECT_STATUS_CODES: 内部错综复杂的重定向追踪及判断逻辑抽离成为单独的 _handle_qzone_redirect(...) 辅助方法，从而保持主请求流程的线性易读。

---

qzone_bridge/controller.py

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

• 违规：引入并使用了自定义日志 from .astrbot_logging import get_logger; log = get_logger(__name__)，违反框架强制要求。

可维护性与可读性：

• 职责不明确与过长的函数：ensure_running 方法承担了极其庞杂的职责，涵盖了“健康探测”、“端口可用性扫描”、“子进程拉起及异常退避”、“进程轮询超时控制”，以及在 finally 级别的存储状态同步。它将流程控制与状态管理过度耦合在了一起。
• 建议：建议将进程挂载与监控拆分为 _spawn_and_wait_health(port)，主方法只需负责获取端口与组装最终返回的状态字典即可。

---

qzone_bridge/daemon.py

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

• 违规：使用了违规的私有日志包装器 from .astrbot_logging import configure_standalone_logging, get_logger。

代码质量与编码规范：

• 闭包滥用：在 create_app 函数中，定义了近 15 个路由处理函数（如 health, status, bind, post 等）作为内部闭包。这不仅让 create_app 膨胀到了超过 120 行，而且每次挂载时都会重新分配这些函数。
• 建议：鉴于这本身已经是一个类（QzoneDaemonService）体系，建议将这些路由处理函数转移到外部，作为独立函数并将其与 service 实例解绑，或者注册到基于 Class 的 View 中。

---

qzone_bridge/media.py

潜在缺陷或问题：

• 系统资源与边界异常风险：在 is_supported_image 方法内部存在代码 suffix = Path(name or source).suffix.lower()。但在上游解析中，source 完全有可能是一长串合法的 Data URI（如 data:image/png;base64,iVBORw0K...）且没有携带 name。将体积庞大的 base64 字符串直接丢进底层的 Path() 对象中，极易触发操作系统层面对路径长度的最大限制异常（OSError: [Errno 36] File name too long），从而导致插件在遇到某些直接发图场景时发生不可预期的崩溃。
• 建议：在进行 Path 实例化前，应该预先增加一个检测条件 if _is_base64_source(source): return False（或者依赖前一行的 mime_type 判断后直接放行），阻断将 Data URI 误作为文件路径去解析的危险行为。

---

代码评审团

人物一（Linus Torvalds）：
我盯着你的 astrbot_logging.py 看了好一会儿。说真的，你们为什么总是对创造新的“兼容抽象层”有着病态的执念？规则已经像大锤一样砸在脸上了——“只能使用框架提供的 logger”，然后你居然自己造了一个假装是 logging 的轮子并把它导回到每一个文件里！把这些“聪明过头”的包装代码全删掉！代码越少，出 Bug 的地方就越少，别在框架明确禁止的地方秀杂技。

人物二（Steve Jobs）：
用户想要的是直觉般顺滑的体验，而我在看你的 client.py 里的 _request_text 时，就像在看一台内部线缆缠绕在一起的老式个人电脑。你把重试、异常捕捉、甚至复杂的重定向黑名单全部塞进了这一个循环里，它根本不够优雅，没有展现出对极致简洁的追求。你的重定向处理机制应该像黑盒子一样独立并且漂亮，而不是跟底层网络请求搅成一团泥浆。

人物三（Elon Musk）：
我们用第一性原理来思考一下 media.py 的问题：一个 Base64 字符串从物理本质上来讲是一堆承载着像素数据的长文本内存块，而不是硬盘里的文件路径节点。所以你用 Path() 去硬塞一段几兆大小的 Base64 文本并试图获取它的.suffix，这在算力和逻辑上都是极其荒谬的。这种对工具的误用会极大增加你的异常崩溃率，必须在输入验证阶段立刻把它拦截或重定向到正确的 Mime 解析器上去。

---

🔍 审核摘要

统计信息

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

daemon_main.py
main.py
qzone_bridge/__init__.py
qzone_bridge/astrbot_logging.py
qzone_bridge/client.py
qzone_bridge/controller.py
qzone_bridge/daemon.py
qzone_bridge/drafts.py
qzone_bridge/errors.py
qzone_bridge/json_store.py
qzone_bridge/llm.py
qzone_bridge/media.py
qzone_bridge/models.py
qzone_bridge/onebot_cookie.py
qzone_bridge/parser.py

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

---

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

当前仓库：diaomin66/astrbot_plugin_qzone_ultra
剩余触发次数：1

[diaomin66]

@Soulter 大佬麻烦看看 十分感谢