插件质量报告
插件:
direct_message_limitHook 功能范围 循环 使用频率 文件读写 修改系统表 读写系统表 读写自己的表 notification.direct.allow 非系统hook 否 1 - - app_notifications - 颜色说明:黄色表示有数据读写,红色表示 Hook 在系统循环中执行,浅蓝色表示有文件写入。“列表跳过”表示回调在列表路径会提前返回,“回调内”表示操作位于回调自身或其帮助函数的循环体内。只有操作实际处于可执行的循环路径时,才会标记“修正❗️”。
数据字典
未检测到插件数据表声明。
🔍 插件审查报告(对照《AI 开发规则》与开发者文档)
代码结构清晰、后台鉴权与 CSRF 到位,但核心 Hook 不存在导致插件当前无法生效,需优先解决。
🔒 安全问题
未发现明显问题。后台入口调用
need_admin(),表单含form_token()。⚡ 性能问题
未发现明显问题。限流为单条
COUNT(*)聚合查询,无循环查询。🐛 功能/规范缺陷
plugin.php:50挂载notification.direct.allow,但核心index.php中不存在该 Hook:私信发送路径user_notify_page直接调用create_notification(...,'direct',...)(index.php:2356),create_notification内也没有任何 allow 拦截点。因此限流回调永远不会被触发,插件实际不起作用。建议与核心协调在私信发送前增加可拦截 Hook,或改用现有拦截点实现限流。plugin.php:24内联 CSS 直接写font-size:13px、font-size:12px,未使用--font-size-sm/--font-size-xs变量,建议改用主题 CSS 变量。
✅ 修复优先级
必须先落地/接入一个真实存在的拦截 Hook(否则功能为空),再按规范修正字号变量。
🔍 插件审查报告(AI 自动审查,对照《AI 开发规则》与开发者文档;本插件未被 8/18 楼上 350 的报告覆盖,属独立首次审查)
插件:私信限制(direct_message_limit)v1.0.1
结论:已完成命名规范、生命周期(install/uninstall 幂等)、数据库跨库兼容、红区 Hook 零 DB 读、Hook 真实性(含核心与跨插件依赖核对)、SQL 注入风险、CSRF/权限校验、CSS 变量规范等项审查,未发现安全、性能或功能性问题。
旧格式迁移:已将插件代码转存到开发日志,主题正文改为基础介绍。