[开发] FlintHub 插件开发规划 · 总索引20261031

👑Lv.11 元老 🌞 骨干会员
2026-10-31 17:06:42

文档集版本:2.0 · 更新日期:2026-10-30 · 状态:有效 代码基线:FLINTHUB_VERSION = V1.3.1(version.php:8) 编写依据:docs/插件开发规范.md v1.7(2026-10-21) 本次修订:对 28 份原始方案做存量能力比对,给出定级结论,并按开发文档标准重整结构。


1. 这套文档怎么用

本目录不是「待办功能清单」,而是经过存量盘点后的决策文档集。站点已有 88 个插件,核心能力在 V1.3.1 也已补齐多轮,因此原始 28 份方案里有相当一部分与现状重叠。开工前必须先看定级结论,再决定是否动手。

想知道什么看哪里
这批方案哪些该做、哪些别做、为什么01-规划定级台账
每个方案的完整技术设计plans/ 目录,按编号
所有插件都适用的硬规则、验证基线00-通用合规基线
一份方案该写成什么结构才算合格02-开发文档规范
原始未经盘点的版本_archive/original/(只读留档,勿引用)

2. 定级总表(28 项)

四类结论,含义见 02-开发文档规范 §3。

2.1 可直接开发(13 项)——站点无等价能力,方案可原样落地

#方案目录一句话价值优先级
01两步验证twofactor密码之外的第二因子,账号安全底座P1
02客服工单support_ticket申诉/故障的闭环服务台P2
08拍卖行auction_house稀缺品的竞价分配P3
09在线聊天室chat_room实时公共频道P3
10抢楼活动floor_event楼层驱动的运营活动P2
11生日祝福birthday低成本留存触点P3
12问卷表单form_builder结构化收集与统计P2
14RSS 输出rss_feed内容外部分发通道P2
15Webhook 推送webhook_push事件外流到外部系统P2
17WebPush 通知web_push浏览器级触达P3
18相册图床photo_album用户图片资产的组织层P2
19百科知识库wiki沉淀型内容载体P3
21时光胶囊time_capsule情绪型玩法P3

2.2 需要插件增强(8 项)——不新建插件,改扩建现有归口

#方案归口缺的是什么处置
06竞猜投注quiz_duel + dice已有 1v1 对赌与押大小,缺「多人同池、赔率浮动」模式在对赌体系内加「群押池」模式,不建第三套押注
07抽卡图鉴lucky_draw权重/库存/稀有度 N·R·SR·SSR 池已具备,缺「图鉴收集」层给 lucky_draw 加图鉴册,不复制抽奖内核
20相关帖子推荐feed_algo已离线算共现图谱与兴趣衰减,缺详情页「相关」面板出口在 feed_algo 增设 right_sidebar_after 面板
22私信站内信核心 /message核心是「邮件式」(主题+正文),缺会话合并、未读角标、软删做会话层包装插件,复用 messages 表,不建独立库
23关注粉丝user_profileuser_follows 表与 follow/unfollow/列表已完整,缺关注动态流直接给 user_profile 加 /follow/feed,不新建插件
24帖子编辑历史edit_info现有表只存 edited_by/edited_at,无内容快照扩 edit_info 加版本表与 diff,不与它抢同一钩子
26帖子打赏inspiration_square已有完整打赏 Saga + 手续费账本,但只服务作品页抽出通用打赏服务,扩展到帖子/楼层粒度
28数据备份核心 Admin\DatabaseController核心已做 WAL checkpoint + 全 data/ 打包 + 轮转 10 份,但不含 70 个插件库(递归含嵌套队列库共 73 个)与 uploads/只补插件库与上传目录,核心库备份部分整段删除

2.3 需要重新制作(2 项)——现有实现语义错误,扩建不如重写

#方案现状问题处置
16短信验证码third_party_login 有 sms_codes/sms_rate 表与验证码逻辑,但没有任何网关调用(只有 access_key/sign_name/template_code 配置键),短信登录实际不可用抽出独立通用短信服务(驱动 + 防刷矩阵 + 手机绑定),third_party_login 经钩子事件改调
27VIP 会员points_mall 的 VIP 商品是 updateGroupId() 永久换组,无到期、续费、降级概念,且污染核心用户组独立做时长制会员,points_mall 的 VIP 商品改为调用它

2.4 不做 / 暂缓(5 项)

#方案为什么不做已有替代
03表情回应核心点赞 + like_points 的档位浮层已提供多档表态;再叠一套 per-表情计数,维护成本高于感知收益核心 votes + like_points
04宠物系统与 xiuxian 同为挂机养成,同质化严重xiuxian(挂机修仙)
05开心农场同上,且「偷菜」的原子扣减复杂度最高xiuxian
13兴趣圈子核心版块体系已覆盖分区讨论;圈子差异化仅「用户自建 + 审批」,可由管理员代建版块替代。且这是 28 项里最重的方案核心版块 + suiyu 动态流
25回帖可见核心 threads.reply_to_view 已实现整帖「回帖可见」,props 的「回复可见卡」可售卖;段级 [hide] 会新增 RSS/mobile_api/搜索摘要的泄漏面核心 reply_to_view + props

3. 建议推进顺序

定级之后只剩 23 项有效方案,按「补缺口 → 低成本高感知 → 重活」三档推进。

第 0 批  修语义(先做,避免带病扩张)
  16 短信服务重制(第三方登录的短信通道当前不可用)
  28 备份补插件库(70 个插件库 + uploads 不在核心备份范围,是真实风险)
  27 VIP 时长制(points_mall 永久换组会污染用户组)

第 1 批  安全与内容底座
  01 两步验证 → 12 问卷 → 02 工单

第 2 批  低成本高感知(增强类优先,改动面小)
  22 私信会话层 → 23 关注动态流 → 24 编辑历史版本链
  20 相关推荐面板 → 07 图鉴册 → 26 通用打赏

第 3 批  运营与外部分发
  10 抢楼 → 14 RSS → 15 Webhook → 18 相册

第 4 批  重活(最后)
  08 拍卖 → 09 聊天室 → 19 百科 → 17 WebPush → 06 群押池 → 11 生日 → 21 时光胶囊

4. 跨方案共性结论(规避重复踩坑)

盘点过程中确认的、多份方案共享的运行时事实,动手前不必再核一遍:

结论影响方案证据
核心私信是「邮件式」,messages 表无会话 ID、无软删22app/SplitDB/Schema.php messages 建表语句
核心 reply_to_view 未授权时正文根本不下发,视图只输出锁定提示25app/Controllers/ThreadController.php:226,281
核心备份走 VACUUM INTO → wal_checkpoint(TRUNCATE) → Database::closeAll() → 打包 data/ 全树 → 轮转 10 份28app/Controllers/Admin/DatabaseController.php handleBackup()
插件库位在 plugins/*/data/*.sqlite,直接 70 个(递归含队列库 73 个),不在 ShardRouter::dataPath() 之下28find plugins -name '*.sqlite'
points_mall 的 VIP 商品只改 user_groups,无到期字段27plugins/points_mall/Plugin.php case 'vip'
登录只有 auth_login_check(置 $GLOBALS['mod_system_login_blocked'] 拒绝)与 auth_login_after,没有「待验证」中间态01docs/插件开发规范.md §9.1 #26/#27
edit_info 的 edit_history 表只有 edited_by/edited_at,无正文列24plugins/edit_info/Plugin.php DDL
user_follows 表 + follow/unfollow/followers/following 均已在 user_profile 内23plugins/user_profile/Plugin.php:403,425,511
lucky_draw 奖品池已含 rarity(N/R/SR/SSR)、权重、库存07plugins/lucky_draw/Plugin.php
suiyu 自带一套关注:sy_follows(follower_id, followee_id),与 user_profile.user_follows(follower_id, followed_id) 列名都不同,数据互不相通23plugins/suiyu/Plugin.php:86 vs plugins/user_profile/Plugin.php

⚠️ 两套关注并存且列名不同:user_profile.user_follows 用 followed_id,suiyu.sy_follows 用 followee_id,是两张互不相通的表。做 23 时必须先决定以哪套为准,否则会出现「主页显示已关注、suiyu 动态流里没有」的割裂。


5. 文档集结构

插件开发规划/
├── README.md                     ← 本文件:索引 + 定级总表 + 推进顺序
├── 00-通用合规基线.md            ← 28 项共用的硬规则与验证基线([B*] 编号)
├── 01-规划定级台账.md            ← 逐项定级结论、依据、证据位置、处置动作
├── 02-开发文档规范.md            ← 一份方案的标准结构、状态口径、评审要点
├── plans/                        ← 28 份方案正文,统一前置元信息块
│   ├── 01-twofactor-两步验证.md
│   └── ...(按编号 01~28)
└── _archive/
    └── original/                 ← 盘点前的原始 28 份 + 旧 README,只读留档
轻量级、高性能、零 MySQL 依赖的PHP社区系统。
| 浏览 8 次 | 回复 0 次

全部回复 (0)

暂无回复

请 登录