[performance]性能优化热
82010
glod2026-08-05
质量报告2026-08-05插件质量报告
插件：
performanceHook 功能范围 循环 使用频率 文件读写 修改系统表 读写系统表 读写自己的表 app.boot 全站请求启动 回调内 5 读写 修正❗️ app_topics 修正❗️ app_topics 修正❗️ - page.before_render 全站页面输出前 否 5 - - - - page.head 全站页面 head 否 5 - - - - reply.after_render 主题查看页/回帖列表逐条渲染 是 5 - - - - topic.after_render 首页/版块列表/主题查看逐条渲染 是 5 - - - - topic.index_data.load 首页/版块/用户主题列表查询前 回调内 5 读写 修正❗️ - - - topic.index_data.loaded 首页/版块/用户主题列表查询后 回调内 5 读写 修正❗️ - - - topic.replies_data.load 主题查看页回帖查询前 回调内 4 读写 修正❗️ - - - topic.replies_data.loaded 主题查看页回帖查询后 回调内 4 读写 修正❗️ - - - reply.after_save 回帖保存后 回调内 3 读写 修正❗️ - app_topics - topic.after_save 主题保存后 回调内 3 读写 修正❗️ - - - topic.before_save 主题发布/编辑表单提交 回调内 3 读写 修正❗️ - app_topics - user.after_save 用户注册/资料保存后 回调内 3 读写 修正❗️ - - - content.before_delete 内容删除操作 回调内 2 读写 修正❗️ - app_topics - performance.cache_invalidate 非系统hook 回调内 1 读写 修正❗️ - app_topics - 颜色说明：黄色表示有数据读写，红色表示 Hook 在系统循环中执行，浅蓝色表示有文件写入。“列表跳过”表示回调在列表路径会提前返回，“回调内”表示操作位于回调自身或其帮助函数的循环体内。“文件批处理”表示逐个处理用户一次提交的文件，属于必要操作，不标记修正。只有操作实际处于需要优化的循环路径时，才会标记“修正❗️”。
数据字典
未检测到插件数据表声明。
- glod2026-08-05
针对的都是访客相关的缓存，已登录用户的缓存优化搞了几版都不太满意后面AI说要核心增加几个hook才行感觉就复杂了目前将就用🤣
“
不能只靠插件“凭空增加”核心调用点。插件只能监听核心已经执行的 Hook；当前唯一真正位于 SQL 前的入口是app.boot，适合整页缓存，不适合登录用户的数据片段缓存。最合理的方案是在核心增加四个通用调用点，缓存实现仍全部放在插件：
topic.index_data.load // SQL 前，插件可返回列表数据 topic.index_data.loaded // SQL 后，插件保存列表数据 topic.page_data.load // SQL 前，插件可返回主楼和分页回复 topic.page_data.loaded // SQL 后，插件保存查询结果核心只负责调用 Hook 和校验返回结构；插件负责 JSON 文件、并发锁、Debug 绕过和事件失效。权限检查、CSRF、未读状态及操作按钮仍由核心实时执行。
技术上也能通过插件覆盖
home/forum/topic路由并复制整套页面逻辑，但会重复核心代码、破坏其他插件兼容，不建议。若要求真正降低登录用户 SQL，增加上述少量通用 Hook 是最安全的边界。” 
bbs1org2026-08-05- glod2026-08-05
性能优化插件主要功能：
访客全页缓存：缓存首页、版块页和帖子页，大幅提升访问速度。
贪婪缓存模式：页面无发帖、回复、编辑等变化时持续复用缓存。
事件驱动失效：发帖、回帖、编辑、删除、移动及管理操作后精准清理缓存。
查询缓存优化：减少重复 SQL 查询，兼容 SQLite、MySQL 和 PostgreSQL。
传输与前端优化：支持 ETag/304、Gzip、图片懒加载和离屏渲染。
安全与兼容：Debug 模式完全绕过缓存，并提供插件兼容 Hook。
- bbs1org2026-08-05
新增了4个hook，只给列表数据、主题回复数据 增加了缓存接口 topic.index_data.load topic.index_data.loaded topic.replies_data.load
topic.replies_data.loaded 
秦始黄2026-08-05有用 不错的 插件 登录状态也加上吧
3502026-08-18🔍 插件审查报告（对照《AI 开发规则》与开发者文档）
🔒 安全问题
未发现明显问题（红区钩子 topic.after_render / reply.after_render 调用链内未发现数据库读取，配置输出均经 h() 转义）。
⚡ 性能问题
未发现明显问题（页面缓存、查询缓存与并发锁设计合理，未发现循环逐条查询）。
🐛 功能/规范缺陷
- 跨插件读取：plugin.php:234 安装时用
SELECT config_json FROM app_plugins WHERE id='modsecurity'读取另一个插件配置做迁移，插件之间不宜直接依赖，建议改为版本化迁移或移除。 - 遗留命名：plugin.php:1191 路由名
modsecurity_sw、plugin.php:1154 Service Worker 里的bbs1org-cache-前缀均沿用旧插件，建议统一改为performance前缀。 - 相对时间定位不可靠：plugin.php:901-907 用 human_time() 输出文本作为替换锚点（首个
<span>刚刚</span>），可能命中错误元素导致data-performance-time错位，建议改用结构化占位标记。 - 硬编码第三方预热：plugin.php:939 无条件输出第三方头像服务域名的 dns-prefetch/preconnect，建议加开关并允许自定义。
✅ 修复优先级
先处理遗留命名与跨插件读取（易引发冲突），再优化相对时间占位与第三方预热开关。
- 跨插件读取：plugin.php:234 安装时用
- glod2026-08-18
版本 1.8.5 更新：
1.支持文章和列表缓存
2.缓存文件清单在单次请求内复用，减少重复目录扫描。
3.缓存清理、统计、淘汰路径取消无用排序。
4.保持缓存上限与最旧文件淘汰逻辑。
5.其他问题修复 - 3502026-08-18
🔍 复核报告（v1.8.5，回应此前审查）· @glod
✅ 已确认修复
- 跨插件读取已移除：performance_install 现在只读自身 $plugin['config']（plugin.php:295-300），全文件已无 modsecurity 引用——正确。
- 遗留命名已清理：路由名改为 performance_sw（plugin.php:1479），Service Worker 缓存前缀改为 'performance-cache-'（plugin.php:1438）——均正确。
- 相对时间锚点已结构化：改用 data-performance-time 属性做标记并展开（plugin.php:790-793），插入端在 performance_mark_time_placeholder（plugin.php:1204-1209），不再用 human_time() 文本当锚点——正确。
❌ 未生效 / 新问题
- 头像预热域名仍硬编码：plugin.php:1222 无条件输出 //api.dicebear.com 的 dns-prefetch/preconnect，只加了 resource_hints_enabled 开关（plugin.php:41、1424），「允许自定义域名」未实现。建议域名入配置项并默认关闭。
- 其余未发现新问题：红区钩子 performance_render_images（topic/reply.after_render，plugin.php:1473-1474）仅读静态配置与 $ctx，零 DB 读；页面缓存拒绝 POST 表单与登录态（plugin.php:694、815），无 CSRF 泄漏。
💡 顺带建议
page.head 的第三方预连接会向 api.dicebear.com 暴露访客来源，建议仅登录态开启或默认关闭。
总结：上一轮的命名/跨插件/锚点问题已修，仅剩预热域名硬编码一项，插件基本干净。
3992026-08-28🔍 插件审查报告（AI 自动审查，对照《AI 开发规则》与开发者文档；本插件未被 8/18 楼上 350 的报告覆盖，属独立首次审查）
插件：performance v1.8.5
🔒 安全问题
未发现明显问题。缓存文件命名与目录均带插件前缀，文件锁防止并发写入冲突。⚡ 性能问题
未发现新增问题；插件本身即为性能优化工具，页面/查询缓存失效逻辑覆盖主题、回帖、用户变更及内容删除等场景。🐛 功能/规范缺陷
manifest 注册了 performance.cache_invalidate 事件的处理函数（performance_invalidate_filter），但全项目范围内未发现任何地方真正调用 hook()/fire() 触发这个事件名——它看起来是预留的扩展点（供未来插件主动请求缓存失效），但目前没有任何调用方，属于"死注册"：处理函数永远不会被执行，不影响现有功能，但属于冗余代码。✅ 修复优先级
低优先级：若该扩展点确实是预留设计，建议在代码注释或文档中说明用途和调用方式；若已废弃，可考虑移除以减少维护负担。