本文由 FlintHub 开发文档归档发布。原始文档日期见标题前缀，来源：暂存20260913/FlintHub_vs_flatbb_对比报告.md。
FlintHub vs flatbb 全局对比报告（修订版）
日期：2026-09-10
方法：精读 flatbb
core/全部 22 文件 +app/核心路由 + FlintHubindex.php、app/Core/、app/Helpers/、app/Controllers/、nginx-server.conf、.htaccess原则：逐层对位，给出行号证据。flatbb 好的地方说清楚好在哪、FlintHub 为什么当前设计不需要照搬；FlintHub 强的地方也如实写。
一、架构定位（不是同一类东西）
| 维度 | flatbb (0.1.66) | FlintHub |
|---|---|---|
| 代码规模 | ~5000 行核心（22 个函数式文件） | ~15000+ 行（MVC 类 + 102 个 PHP 文件） |
| 架构 | 纯函数 + 显式 require，无自动加载 | PSR-4 自动加载 + Controller/Model/Helper 分层 |
| 数据库 | 单库（SQLite/MySQL 双驱动），fb_ 前缀 | SQLite SplitDB 分片（季度桶 + main_index + 队列库），无 MySQL 驱动 |
| 搜索 | FTS5 / MySQL FULLTEXT / LIKE 三级降级 | 自研中文分词倒排索引（Segmenter）+ 多季度归并 + LIKE 降级 |
| 认证 | 无状态签名 Cookie（uid.exp.hmac） | PHP Session（DB 存储）+ RememberMe 双 Cookie |
| 模板 | <?= h() ?> 手动转义 + region 槽位 | TemplateCompiler 编译缓存，{var} 默认自动转义 |
| 页面缓存 | 无（仅细粒度设置缓存） | 游客整页静态缓存（data/runtime/pages/） |
| 插件 | manifest 数组声明，zip 安装 | 类 + hooks + 独立 SQLite 库 + 权限声明强制 + 统一 HTTP 出口 |
| 语言 | 9 种 | 3 种（zh/zh_tw/en） |
| Web 防护 | .user.ini 自动写入 + 安全自检探针 | nginx-server.conf + .htaccess 双轨 deny 规则 |
| 测试 | tests/（core/markdown/security） | cli/ 冒烟脚本 |
定位差异：flatbb 是"极简单体"，目标是一个能跑、好读、好改的小论坛；FlintHub 是"可分片扩展"，目标是支撑几十万帖、多插件、中文搜索的中型社区。两者不在同一条赛道上，直接对比"谁好"意义不大——要看的是：flatbb 有哪些工程细节值得吸收，FlintHub 有哪些设计是 flatbb 根本做不到的。
二、安全层逐层对位（这是上次报告最薄弱的部分）
2.1 请求入口与全局防护
| 防护项 | FlintHub | flatbb |
|---|---|---|
| 错误泄露 | index.php L11: error_reporting(0) + display_errors=Off；L294-299 全局 catch，500 只输出通用提示，详情进 error_log | core/boot.php 同样关 display_errors；catch 在 app/index.php 里 |
| 会话安全 | index.php L25-29: httponly + samesite=Lax + secure + UseOnlyCookies + UseStrictMode | Cookie 认证，httponly+samesite 由 security_headers() 设置 |
| HSTS | index.php L15-16: Strict-Transport-Security max-age=31536000; includeSubDomains | security.php 有 HSTS（max-age=31536000） |
| 全局异常 | index.php L292-300: try-catch 包裹 dispatch，500 不泄露堆栈 | app/index.php 同样有 catch |
| 请求速率 | RateLimiter::beforeRequest()（index.php L206）：每请求入口即执行 | 无全局入口级速率限制，只有登录限流 |
结论：入口层 FlintHub 更完整。RateLimiter::beforeRequest() 是全局拦截器，在路由分发之前就执行；flatbb 没有对应物。
2.2 速率限制（防暴力/防滥用）
| 场景 | FlintHub `RateLimiter.php` | flatbb |
|---|---|---|
| 登录 | L42: 10次/15min/IP + L43: 5次/user + L44: 全局 100次/min | account.php L12-15: 同 IP 失败计数，阈值 5 次锁 15min |
| 注册 | L47: 10次/user/24h + L48: 30次/IP/24h + L49: 全局 60次/min | account.php L38-42: 同 IP 30 次/24h |
| POST 洪水 | L50: 30次/min/IP 全局拦截 | 无 |
| 后台操作 | L51: 60次/min/IP | 无 |
| API 端点 | L52: 60次/min/IP；L54: 投票 10次/s/30min | 无 |
| 图片抓取 | L40: 5次/min/IP | 无 |
| 降级兜底 | L91-127: APCu 不可用时 Session 级兜底 | 无 |
结论：FlintHub 的速率限制是多维度、分端点、有全局兜底的；flatbb 只有登录和注册两个场景。这是 FlintHub 明显的优势。
2.3 CSRF 防护
| 维度 | FlintHub `Csrf.php` | flatbb `security.php` |
|---|---|---|
| Token 生成 | HMAC-SHA256(session_id, user_id, site_key) — 无状态，不查库 | csrf_token() — 基于 Session 存储 |
| 验证 | hash_equals() 常数时间比较 | hash_equals() |
| 覆盖范围 | 所有后台 POST（BaseController::before()）+ 前台关键操作（登录/注册/发帖/投票） | 所有 POST（csrf_verify() 在 app/index.php 入口调用） |
| 失败响应 | 403 + 中文提示 | 403 + 英文提示 |
结论：两者水平相当。FlintHub 的 HMAC 无状态设计略优（不占 Session 存储），flatbb 的入口统一调用略简洁。
2.4 认证与会话
| 维度 | FlintHub | flatbb |
|---|---|---|
| 登录态 | Session（DB 存储）+ RememberMe（sha256 token + 7/30天） | 无状态签名 Cookie（uid.exp.hmac，HMAC 材料含 auth_salt） |
| 登录时 Session 固定 | Auth::login() 内部 session_regenerate_id(true) | N/A（无 Session） |
| 改密后全端登出 | RememberMe::clearTokens()（AuthController.php L404）— 吊销全部记住登录 token | user_logout_everywhere()（auth.php）— 轮换 auth_salt，所有签名 Cookie 失效 |
| 后台二次验证 | Session 标记（30min/30day 两档） | 签名 Cookie（HMAC + 可配 TTL 0-1440min） |
| 权限 | Auth::isAdmin() 查 role 字段 | user_role() 查 role 字段 |
结论：两者各有优劣。
- flatbb 的
auth_salt轮换更彻底——改密码后所有已签发 Cookie 立即失效，而 FlintHub 只清 RememberMe token，当前 Session 仍有效（需等 Session 过期或手动登出）。 - FlintHub 的 Session + DB 方案更灵活（可以在后台实时踢人、查看在线用户），flatbb 的无状态 Cookie 更简单但无法主动撤销。
- 后台二次验证：flatbb 的签名 Cookie 比 FlintHub 的 Session 标记更安全（Session 被注入/篡改时验证状态可被伪造），但 FlintHub 的 30 天模式是面向"长时间运维操作"场景的，flatbb 的 0-1440min 上限没有覆盖这个场景。
2.5 文件上传安全
| 维度 | FlintHub `Upload.php` | flatbb `upload.php` |
|---|---|---|
| 扩展名白名单 | 硬编码（png/jpg/gif/webp/svg/mp4 等） | 可配置（upload_allowed_ext） |
| MIME 校验 | 硬编码 $allowedMimes 映射表（L61-73），白名单之外的扩展名即使加入也会被 MIME 校验拦截 | 无 MIME 校验（仅扩展名） |
| 文件名 | uniqid() + random 随机化 | random(16) 随机化 |
| Null byte 检测 | 有（L55） | 无 |
| 原图缩放 | 仅生成 thumb_ 小图，原图多大存多大 | 自动缩放到最长边 1600px（upload_shrink_image） |
| 存储路径 | UPLOAD_PATH 平铺 | uploads/YYYY/MM/ 日期分片 |
| MD5 去重 | 无 | 有（附件表存 md5_file） |
| 目录防护 | nginx-server.conf L54 + .htaccess L24：assets/uploads/.*\.php$ deny 403 | 自动写 .user.ini（engine=Off）+ .htaccess（upload_protect_dirs） |
| 像素炸弹防护 | 有（Imagick 解码前检查尺寸） | 无 |
结论：FlintHub 的防御纵深更强（MIME 校验 + 像素炸弹 + Web 服务器 deny），但 flatbb 在工程实用性上更好（原图缩放省存储、日期分片避免单目录大文件数性能劣化、MD5 去重可审计）。
2.6 SQL 注入防护
| 维度 | FlintHub | flatbb |
|---|---|---|
| 参数化查询 | Model.php 全部 prepare() + 绑定参数 | db.php L55-61: q() 全部 prepare() + 绑定参数 |
| 列名注入 | Model.php: insert()/update() 列名正则校验 + $fillable 白名单 fail-closed | 无 ORM 层，靠代码手工构造 data 数组 |
| WHERE 注入 | Model.php buildWhere(): 严格白名单解析器，拒绝 OR/子查询/字面量 | 无对应层，靠代码规范 |
| 表前缀 | 无前缀（表名硬编码） | fb_ 前缀 |
结论：FlintHub 的 Model 层有三层防护（参数化 + 列名白名单 + WHERE 解析器），flatbb 只有参数化一层。在 15000+ 行代码中，Model 层的自动防护比"靠代码规范"可靠得多。
2.7 XSS 防护
| 维度 | FlintHub | flatbb |
|---|---|---|
| 模板转义 | {var} 自动 htmlspecialchars(ENT_QUOTES, UTF-8)，仅 {!! !!} 显式 raw | <?= h() ?> 手动调用，漏一个就是 XSS |
| 用户内容存储 | 发帖时 Content::clean() 过滤 HTML（保留白名单标签） | 发帖时 clean_content() 过滤 HTML |
| CSP | Controller::setSecurityHeaders(): script-src 'self' 'unsafe-eval' 'unsafe-inline' | security.php: script-src 'nonce-xxx'（无 unsafe-inline）+ Report-Only/Enforce 可配 + /csp-report 端点 |
结论：模板层 FlintHub 更优（默认转义，开发者不需要记得调函数）。但 CSP 层 flatbb 更优——FlintHub 的 'unsafe-inline' 'unsafe-eval' 等于 CSP 形同虚设，flatbb 的 nonce 机制是真正可用的 CSP。
2.8 SSRF 防护（远程图片抓取）
| 维度 | FlintHub `ApiController::fetchImage()` | flatbb |
|---|---|---|
| 私有 IP 拦截 | 有（IPv4: 10/172.16-31/192.168/127/169.254；IPv6: ::1） | 无（无此功能） |
| DNS 预解析 + IP pinning | 有（先 gethostbyname 解析，再连接到解析后的 IP） | 无 |
| 重定向限制 | 3 跳，每跳重新检查 IP | 无 |
| 响应体限制 | 2MB | 无 |
| 超时 | 15s | 无 |
| MIME 校验 | 有 | 无 |
| 速率限制 | 5次/min/IP | 无 |
| IPv6 盲区 | 缺 ULA(fd00::/8)、Link-Local(fe80::/10)、IPv4-Mapped(::ffff:10.x) | N/A |
结论：FlintHub 的 SSRF 防护是完整的纵深防御体系（DNS pinning + 私有 IP 拦截 + 重定向限制 + 大小限制 + 超时 + MIME + 限流），flatbb 根本没有这个功能。FlintHub 唯一的问题是 IPv6 黑名单不完整（上次报告已指出）。
2.9 Web 服务器层防护
| 维度 | FlintHub | flatbb |
|---|---|---|
| 敏感目录 deny | nginx-server.conf L42-51: data/ protected/ cli/ plugins/*/data/ 全部 403 | 无（依赖 .user.ini engine=Off） |
| 上传目录禁 PHP | nginx-server.conf L54: assets/uploads/.*\.php$ 403 | .user.ini engine=Off（PHP 不解析） |
| 目录列表 | autoindex off（L110）+ Options -Indexes（.htaccess L45） | 无显式配置 |
| 自定义错误页 | 400-510 全部映射（L97-109） | 无 |
| 双轨配置 | nginx-server.conf（Nginx）+ .htaccess（Apache）等价规则 | 仅 .user.ini |
| 运行时自检 | 无 | admin_security_checks()（admin.php L36-62）：后台主动 curl 探测 /data/index.html、/core/boot.php、/plugins/hello/plugin.php 是否可达，检查 rewrite 是否生效、debug 是否开启 |
结论：FlintHub 的 Web 服务器层防护更完整（nginx + apache 双轨、全错误页、全 deny 规则）。但 flatbb 的运行时自检是 FlintHub 没有的——后台主动发 HTTP 请求探测自己的防护是否真的生效，这能发现"nginx 规则写了但没 reload"之类的运维问题。
2.10 插件安全边界
| 维度 | FlintHub `Plugin.php` | flatbb `plugin.php` |
|---|---|---|
| 权限声明 | 强制（net:fetch/route:admin/system:settings），未声明的插件无法使用对应 API | manifest 数组声明 perms，但无强制校验——插件代码可以直接 file_get_contents 绕过 |
| 统一 HTTP 出口 | Plugin::http()：含 SSRF 防护（私有 IP 拦截 + IP pinning + 重定向限制 + 2MB cap） | 无统一出口，插件直接调 file_get_contents |
| 数据库隔离 | 每插件独立 SQLite 库（Plugin::db('name')） | 共享主库（fb_ 前缀表） |
| zip 安装校验 | 无（手工拷目录） | plugin_install_zip()：强制单一顶层目录 + 拒绝可执行文件 + 剔除 __MACOSX + 校验失败回退 |
| 插件资源 | 每插件独立 css/js 文件 | plugin_assets_build()：合并为 plugins.css/plugins.js 两个文件 |
| 资源缓存戳 | 无（文件 mtime） | md5 短哈希做版本号 |
结论：FlintHub 的运行时安全边界更强（权限强制 + 统一 HTTP 出口 + DB 隔离），flatbb 的安装/分发工具链更完善（zip 校验 + 资源合并）。
2.11 审计日志
| 维度 | FlintHub | flatbb |
|---|---|---|
| 后台操作审计 | AuditLog.php: 记录 user_id/username/ip/before/after JSON，写入 audit_log 表 | 无 |
| 登录/登出记录 | 有 | 无 |
| IP 获取 | AuditLog::getClientIp() 无条件信任 X-Forwarded-For（弱点） | client_ip() 受信代理 CIDR 白名单（更严） |
结论：FlintHub 有审计日志（flatbb 没有），但 IP 获取方式不如 flatbb 严谨。
三、性能与扩展层
3.1 数据库架构
| 维度 | FlintHub | flatbb |
|---|---|---|
| 架构 | SplitDB 分片：季度桶（data/db/2026Q1.sqlite 等）+ main_index 总索引 + 队列库 | 单库（data/flatbb.sqlite） |
| 连接 | 按季度路由到对应桶，跨季度查询走 main_index | 单连接 |
| 写入 | 新帖写入当前季度桶，ViewCounter APCu 内存计数 + shutdown 批量落库 | 直接写主库 |
| 容量监控 | 后台 UI：各桶行数/大小/容量百分比 + 自动扩容（创建下季度桶） | 无 |
| 一致性检查 | 后台按钮：全桶行数 vs main_index 行数对比 | 无 |
| 归档 | 后台操作：冷数据迁移到 legacy 归档 | 无 |
| 升级 | 手动跑 upgrade_p*.php 脚本 | boot.php 启动时版本比对，自动幂等 DDL |
结论：这是 FlintHub 最核心的架构优势。flatbb 单库到几十万帖后查询性能会明显下降（SQLite 单文件越大越慢），FlintHub 的季度分片可以把单文件控制在几十万行以内。flatbb 的自动 schema 同步是 FlintHub 缺少的运维便利。
3.2 搜索
| 维度 | FlintHub | flatbb |
|---|---|---|
| 中文分词 | 自研 Segmenter（按字符/词组分词，建倒排索引） | FTS5 unicode61 分词（对中文是整串切分，不拆词） |
| 索引结构 | 倒排索引表（search_index），支持多季度归并 | FTS5 虚拟表 |
| 搜索体验 | 中文关键词可精确匹配（如"论坛"能匹配到含"论坛"的帖子） | 中文搜索依赖整串匹配，"论坛"只能匹配连续出现"论坛"的帖子 |
| 降级 | LIKE（SQLite 无 FTS5 时） | LIKE（无 FTS5 时） |
| 搜索性能 | 倒排索引 O(1) 定位 | FTS5 全文检索 O(log n) |
结论：FlintHub 的中文搜索是实质性优势。FTS5 的 unicode61 分词器对 CJK 字符不做词法分析，中文搜索体验差。FlintHub 的自研分词虽然比 jieba 等专业分词器粗糙，但对论坛场景足够用。
3.3 页面缓存
| 维度 | FlintHub | flatbb |
|---|---|---|
| 整页缓存 | 游客首页/论坛页/帖子页 → data/runtime/pages/*.html 静态文件 | 无 |
| 缓存失效 | PageCache::invalidate() 手动 + TTL 自动过期 | N/A |
| 登录用户 | 走 PHP 渲染 | 走 PHP 渲染 |
| 细粒度缓存 | 站点统计、分类计数等 | 设置项缓存（setting() 内存 + 文件） |
结论：FlintHub 的整页缓存是纯性能优势，flatbb 没有对应物。
3.4 队列与定时任务
| 维度 | FlintHub | flatbb |
|---|---|---|
| 队列 | 双模式（同步/异步），APCu 内存队列 + SQLite 持久化队列 | core/cron.php: 基于 last_cron 时间戳的懒触发 |
| 定时任务 | 队列消费者（cli/queue_worker.php） | cron_hot_scores（30min）、cron_cleanup（24h） |
| 浏览量 | APCu 内存计数 + shutdown 批量落库 | 直接 UPDATE view_count = view_count + 1 |
结论：FlintHub 的 APCu 内存计数 + 批量落库是更优的写放大控制方案。flatbb 的懒触发 cron 更简单但无法精细控制执行频率。
四、工程与运维层
4.1 插件系统
| 维度 | FlintHub | flatbb |
|---|---|---|
| 注册 | 类 + plugins/plugins_cache.json（含 hooks 清单） | manifest 数组 + 自动发现 |
| 安装 | 手工拷目录 + 手动更新缓存 | zip 上传 + 自动解压 + 校验 |
| 资源 | 每插件独立 css/js | 合并打包 + md5 缓存戳 |
| 钩子 | Plugin::hook('name', $data) 静态调用 | hook('name', $callback) 闭包注册 |
| 布局槽位 | 有 controller_view_before 等钩子，但管理员无法直接插入 HTML | 30+ 命名槽位（header.nav/sidebar.right.cards/footer.links…），管理员后台可直接插入/排序/禁用 |
结论：flatbb 的布局槽位系统是 FlintHub 确实缺少的功能——管理员不改代码就能自定义页面布局。FlintHub 的插件权限强制 + 统一 HTTP 出口是 flatbb 没有的。
4.2 升级与部署
| 维度 | FlintHub | flatbb |
|---|---|---|
| 升级 | 手动跑 upgrade_p*.php | 启动时自动检测版本 → 幂等 DDL |
| 配置 | protected/config.php（DB 连接/密钥等） | data/config.php（同样） |
| Web 服务器 | nginx-server.conf + .htaccess 双轨 | 无（依赖部署者自行配置） |
| 安全自检 | 无 | 后台 curl 探测自身防护是否生效 |
| 开发工具 | 无 | devtools.php: N+1 查询检测、插件版本检查、zip 打包 |
结论：flatbb 的自动 schema 同步和安全自检是 FlintHub 应该借鉴的。FlintHub 的 nginx + htaccess 双轨配置是 flatbb 没有的。
4.3 国际化
| 维度 | FlintHub | flatbb |
|---|---|---|
| 语言数 | 3（zh/zh_tw/en） | 9 |
| 实现 | I18n::get('key', $vars) + 三语言包文件 | t('key') + 语言包 |
| 语言切换 | 前台/后台独立切换（Session 存储） | 前台/后台统一（Cookie 存储） |
结论：flatbb 语言数更多，但 FlintHub 的前后台独立语言切换更实用（管理员可能用中文后台看英文论坛）。
五、模板与渲染
| 维度 | FlintHub | flatbb |
|---|---|---|
| 语法 | {var} 自动转义 / {!! raw !!} 显式 raw / {if} / {foreach} / {include} | <?= 原生 PHP + h() 手动转义 |
| 编译 | TemplateCompiler 预编译缓存到 data/runtime/templates/ | 无编译，直接 include |
| 图标 | $this->icon('name') → 内联 SVG（TemplateCompiler 的 $map） | 无 |
| 布局 | 模板继承（layout 参数） | region 槽位（hook('header.nav', ...)） |
| 组件 | 无 | 无 |
结论：FlintHub 的编译缓存是性能优势（避免每次请求重新解析模板）。flatbb 的 region 槽位是灵活性优势（管理员可自定义布局）。
六、flatbb 真正值得借鉴的思路（修正版）
以下只列 FlintHub 当前设计确实缺少、且 flatbb 的实现方案比 FlintHub 现有方案更好 的项。
1. 统一 client_ip() 函数（安全 P0）
flatbb 做法（core/security.php L15-45）：trusted_proxies 设置项支持 cloudflare 关键字（内置官方 IP 段）+ 任意 CIDR；只有 REMOTE_ADDR 落在受信段内才采信 CF-Connecting-IP/X-Forwarded-For。
FlintHub 现状（两处口径相反）：
RateLimiterL145/L180/L292：只用REMOTE_ADDR→ 反代后所有用户共享代理 IP，限流失效AuditLog::getClientIp()L26-31：无条件信任 X-Forwarded-For 第一个值 → 攻击者可伪造审计日志 IP
为什么 FlintHub 当前设计需要改：FlintHub 的 RateLimiter 和 AuditLog 各自实现了 IP 获取逻辑且口径不一致，这不是"设计选择"而是"缺少统一函数"。加一个 client_ip()（含受信代理 CIDR 校验）替换两处调用，改动面极小。
2. CSP nonce + 违规上报（安全 P1）
flatbb 做法（core/security.php）：每请求随机 nonce 注入 script-src 'nonce-xxx'，无 unsafe-inline；/csp-report 端点收集浏览器违规报告写入带容量上限的日志（512KB 滚动）；模式可配 report/enforce。
FlintHub 现状：Controller::setSecurityHeaders() 写死 script-src 'self' 'unsafe-eval' 'unsafe-inline'——任何内联脚本都放行，CSP 等于没写。
为什么 FlintHub 当前设计需要改：FlintHub 的模板系统（TemplateCompiler）已经把所有 JS 收敛到外部文件（"零内联"约定），'unsafe-inline' 的存在是历史遗留，收紧为 nonce 模式在技术上可行。
3. 后台安全自检探针（运维 P1）
flatbb 做法（app/admin.php L36-62）：后台主动 curl 探测 /data/index.html、/core/boot.php、/plugins/hello/plugin.php 是否可达，检查 rewrite 是否生效、debug 是否开启。结果缓存 1 小时。
FlintHub 现状：无。nginx-server.conf 的 deny 规则写了但没有验证机制——如果 nginx 没 reload 或规则被面板覆盖（.htaccess 注释里已经提到这个风险），防护形同虚设。
为什么 FlintHub 当前设计需要这个：FlintHub 的防护完全依赖 Web 服务器配置，而 phpstudy 面板可能重写 vhost 文件。一个 20 行的自检探针（后台按钮，curl 探测 3 个路径）就能发现配置丢失。
4. 启动时幂等 schema 同步（运维 P2）
flatbb 做法（core/boot.php）：setting('schema_version') !== SCHEMA_VERSION → 自动执行全部幂等 DDL。
FlintHub 现状：手动跑 upgrade_p41.php / upgrade_p115.php。
为什么 FlintHub 当前设计可以借鉴但不必照搬：FlintHub 的 SplitDB 分片结构比 flatbb 复杂得多（多桶 + 索引表 + 队列库），简单的"版本比对 → 跑 DDL"不够用。但可以借鉴思路：把现有 upgrade 脚本改造成"版本号 + 幂等 DDL 集合"，在 init.php 里版本比对后自动执行。
5. 上传原图缩放 + 日期分片（工程 P2）
flatbb 做法（core/upload.php）：图片自动缩放到最长边 1600px 再落盘；存储路径 uploads/YYYY/MM/<random>.<ext>。
FlintHub 现状：原图多大存多大；平铺目录。
为什么值得借鉴：论坛帖子图片往往是手机拍的 4000×3000，原样存盘浪费空间且拖慢浏览器渲染。缩放到 1600px 后文件大小从 ~3MB 降到 ~200KB，对用户体验和存储都是净收益。日期分片避免单目录几万文件后 opendir 变慢。
6. 布局槽位系统（功能 P2）
flatbb 做法（core/hook.php）：30+ 命名布局槽位，管理员后台可直接向任意槽位插入自定义 HTML 块（启用/排序），能按槽位单独禁用某插件的输出。
FlintHub 现状：有 controller_view_before 等钩子，但管理员改布局必须动模板或写插件。
为什么不必照搬 flatbb 的 30 个槽位：FlintHub 的插件系统已经比 flatbb 强（权限强制 + 统一 HTTP 出口），30 个槽位的细粒度对中型论坛是过度设计。可以借鉴思路：把最常用 3-5 个槽位（页头导航后/右栏底部/页脚前/发帖表单附加字段）暴露为后台"自定义内容块"，存 settings 即可。
7. 热门分时间衰减算法（功能 P2）
flatbb 做法（core/cron.php cron_hot_scores）：hot_score = (赞×3 + 回复×2 + 浏览/20) / (小时+2)^1.4，时间衰减抑制老帖霸榜。
FlintHub 现状：forum.hot（热门）目前按最新/浏览量展示，无时间衰减。
为什么值得借鉴：公式简单，加进现有队列任务即可，改动面很小。
8. 插件 zip 安装校验（工程 P3）
flatbb 做法（core/plugin.php plugin_install_zip）：强制单一顶层目录且与插件 id 一致、拒绝可执行文件（exe/dll/so/sh/bat/phar）、剔除 __MACOSX、校验失败整体回退。
FlintHub 现状：手工拷目录 + 手动更新 plugins_cache.json。
为什么值得借鉴但不必照搬：FlintHub 的插件是自有开发（非第三方市场），zip 安装的优先级不高。但可以加一个"插件完整性校验"CLI/后台按钮，按 flatbb 的清单逐项检查（id 一致性、可执行文件、缓存一致性）。
七、FlintHub 的设计不需要照搬 flatbb 的部分（说明原因）
| flatbb 设计 | FlintHub 为什么不需要 |
|---|---|
| 无自动加载的显式 require + 纯函数 | FlintHub 15000+ 行代码，PSR-4 + 类体系是必须的；flatbb 5000 行用函数式是合理选择，但放到 FlintHub 规模会不可维护 |
| SQLite/MySQL 双驱动 | FlintHub 的 SplitDB 分片绑定 SQLite 文件布局（按季度分文件、APCu 缓存、main_index 总索引），双驱动要重写整个分片层，投入产出比极低 |
| 无状态 Cookie 认证替代 Session | FlintHub 的 Session + DB 方案支持后台实时踢人、查看在线用户、前台/后台独立 Session——这些是无状态 Cookie 做不到的。flatbb 的 auth_salt 轮换思路可以吸收（加一列 + 改 RememberMe 哈希材料），但不必推翻整个认证体系 |
| FTS5 全文搜索 | FlintHub 的自研中文分词倒排索引对中文论坛是更优解；FTS5 的 unicode61 分词器不拆中文词，搜索体验差 |
| 无整页缓存 | FlintHub 的游客页静态缓存是性能优势，不需要改成 flatbb 的模式 |
手动 h() 转义 | FlintHub 的 {var} 自动转义更安全（开发者不需要记得调函数），flatbb 的"靠纪律"在 5000 行代码里可以，在 15000+ 行里不行 |
| 共享主库（插件） | FlintHub 的插件独立 SQLite 库隔离更好——一个插件的 DB 损坏不影响主站 |
| manifest 数组插件声明 | FlintHub 的类 + 权限声明 + 统一 HTTP 出口是更强的安全边界；flatbb 的 manifest 只"声明"权限不强制，插件代码可以直接 file_get_contents 绕过 |
| 懒触发 cron | FlintHub 的队列系统（APCu 内存 + SQLite 持久化 + 双模式）更灵活，能处理"发帖后触发搜索索引更新"这类需要参数传递的异步任务 |
| 9 种语言包 | 语言数量取决于目标用户群，不是架构优劣 |
八、总结
FlintHub 的优势（flatbb 做不到的）
- SplitDB 分片——单库到几十万帖会慢，分片可线性扩容
- 中文分词搜索——FTS5 不拆中文词，FlintHub 的 Segmenter 能
- 整页缓存——flatbb 没有
- 插件 SSRF 防护 + 权限强制 + DB 隔离——flatbb 的插件可以绕过权限直接发 HTTP 请求
- Model 层三层防注入——参数化 + 列名白名单 + WHERE 解析器
- 模板默认转义——flatbb 靠开发者记得调
h() - 多维度速率限制——分端点、分用户、全局兜底、Session 降级
- Web 服务器双轨防护——nginx + apache 等价规则
- 审计日志——flatbb 没有
- APCu 内存计数 + 批量落库——写放大控制优于 flatbb 的直接 UPDATE
flatbb 值得借鉴的（按优先级）
| 优先级 | 思路 | 改动量 |
|---|---|---|
| P0 | 统一 client_ip()（受信代理 CIDR） | ~50 行新 Helper + 2 处调用替换 |
| P1 | CSP nonce + 违规上报 | ~80 行（模板改造 + 1 个端点） |
| P1 | 后台安全自检探针 | ~30 行（1 个后台按钮） |
| P2 | 启动时幂等 schema 同步 | ~100 行（改造现有 upgrade 脚本） |
| P2 | 上传原图缩放 + 日期分片 | ~50 行（Upload.php 改造） |
| P2 | 热门分时间衰减 | ~30 行（队列任务） |
| P2 | 布局槽位（3-5 个常用槽位） | ~200 行（后台 + 模板） |
| P3 | 插件完整性校验 | ~50 行（CLI 脚本） |
上版报告的修正
- 搜索：上版报告把 FTS5 归到 FlintHub 名下，实际 FTS5 是 flatbb 的，FlintHub 是自研 Segmenter 中文分词倒排索引。FlintHub 的中文搜索优于 flatbb。
- 安全：上版报告只看了 3 个文件就下了"FlintHub 安全性不如 flatbb"的结论，实际 FlintHub 的安全体系（速率限制/SSRF/SQL 注入/CSRF/Web 防护/审计）比 flatbb 更完整。flatbb 只在 CSP、client_ip、sudo 签名 Cookie 三个点上优于 FlintHub。
- 全局：上版报告只看安全，忽略了架构/性能/工程/运维/模板/国际化等维度的全面对比。
