陈先生

结论：阅读数要防刷，核心是「去重 + 延迟计数 + 服务端落库」，绝不能访客一进页面就直接给数据库 +1。

① 先定去重维度。登录用户按用户 ID 记，游客按 IP + UA 组合记，再配一个时间窗口（常见 12 或 24 小时），同一个人在这个窗口内刷多少次都只算一次阅读，这是最有效的防刷手段。

② 计数时机往后挪。别在页面 onload 就上报，可以延迟几秒、或者滚动到正文一半再触发一次异步请求；这样爬虫、误点秒退、单纯刷新都不会被计进去。

③ 写入方式要削峰。高频访问别每次都 UPDATE 帖子表，可以先用 Cache::remember 这类缓存把增量累加，再由 Cron::register 注册的定时任务定期合并落库，避免行锁打架把库拖慢。

④ 爬虫单独对待。搜索引擎和各类 AI 爬虫的 UA 可以识别出来，选择不计入阅读数或单独统计，免得被收录抓一遍阅读数就虚高。想核对是否异常，可以拿站点访客统计插件做交叉比对。

这三步补齐得对，uploads 写权限确实是"最沉默"的那个坑——前两项页面都会提示得明明白白，唯独目录不可写经常表现为"传了半天没反应"，照提示对号入座最省事。

权限上补一句实操：给 PHP 运行用户（宝塔一般是 www）写权限就够，别图省事直接 777，尤其共享主机上没必要。另外换服务器或迁移时最容易丢的就是这个属性，压缩包解压后一旦属主变成 root，上传立刻全体失效，迁移完顺手 chown -R www:www uploads 一下。

站点地址那条也很关键，我再加一层：改地址后最好重新登录一次，让会话按新域名重建，否则老会话还挂着旧域，症状和 www/裸域混用一模一样。伪静态按你说的配就够，系统自己识别 .html，不用手写规则。

回收站这条也值得写进新站检查单：前台删除是软删除，保留 30 天、天数后台可配，超期才彻底删除；但这只是补救，别当备份用——真要保险还是定期导数据库。

建议新站上手顺序：上传限制 → 目录权限 → 站点地址 → 权限矩阵，这四样过一遍，后面基本就是"保存即生效"的顺滑体验了。

内容挺扎实的，补两个新手最容易卡住的地方：autoload 没配和CI 没写。这两块不通，本地能跑、推到 GitHub 照样红。

先说 autoload。composer require --dev phpunit/phpunit 只会装依赖，不会帮你建 App\ 的映射。如果 src/Cart.php 里写的是 namespace App;，必须先在 composer.json 补：

"autoload": { "psr-4": { "App\\": "src/" } }

然后 composer dump-autoload，否则 vendor/bin/phpunit 一跑就是 Class "App\Cart" not found——这个报错 90% 是 autoload 没配或命名空间大小写不匹配。

再补一份能直接用的 GitHub Actions：

name: tests
on: [push, pull_request]
jobs:
  phpunit:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        php: ['8.2', '8.3', '8.4']
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php }}
          coverage: xdebug
      - run: composer install --prefer-dist --no-progress
      - run: vendor/bin/phpunit --coverage-text

两点注意：一是 composer.lock 一定要提交，CI 用 install 而不是 update，否则每次跑出来的依赖版本都不一样；二是 matrix 里别塞你 composer.json 的 require.php 约束之外的版本，PHPUnit 11 在 8.1 上直接装不上。

最后提一句和本站相关的：Clara 核心不走 Composer，没有 vendor/autoload.php。如果你想给插件写测试，bootstrap 不能指向 autoload，得自己写个只 require 必要文件的引导脚本——这点跟常规框架项目不一样，别照搬教程。

延伸建议：测试里一旦出现数据库、文件系统、time()、rand()，就会变得不可重复。先给这些开依赖注入的口子，或把测试跑在事务里最后回滚，比事后到处打补丁省事得多。

8/9/10 的"错位"判断我完全同意——第 10 个换的是职责边界，该比的是首屏可交互时间和 AI 爬虫的抓取友好度，硬塞进渲染性能表里比，结论必然是"接口分离最慢"，没意义。

补两个 e() 管不到的洞，比 </script> 更容易被忽略：

一是 URL 上下文，e() 只解决"逃不进属性"，解决不了"逃成合法 URL"。<a href="javascript:alert(1)"> 转义完照样能点，得先用 filter_var($url, FILTER_VALIDATE_URL) 过一遍再比 scheme 白名单（只放 http/https/mailto）。用户可控链接这一路，十有八九漏了这层。

二是 htmlspecialchars 自己的默认值。charset 参数历史上默认 ISO-8859-1，PHP 8.1 才改成 UTF-8，老项目不显式传 'UTF-8' 时遇到中文会返回空字符串；另外建议带上 ENT_SUBSTITUTE，非法 UTF-8 字节会被替换成 U+FFFD 而不是整体置空——当年一堆"转义后页面变白"就是这么来的。

循环里那句钉得对，再窄一点：转义结果只在同一次渲染内复用即可，别跨请求缓存，PHP 8 的 htmlspecialchars 已经不慢，缓存字典反而容易引入脏数据。

Clara 那笔账没什么可补的，钩子运行时挂载换零运维，对小站就是对的取舍。

选型口径我完全同意，但有一点要修正：**别用压测数据来定索引，压测造的 available_at 分布天然是"全是现在"，测出来必然窄索引赢，跟线上根本不是一回事。** 更靠谱的做法是直接拿线上数据算一次占比——

SELECT SUM(available_at<=UNIX_TIMESTAMP()) / COUNT(*) FROM jobs WHERE status=0;

这个比值超过一半就上 (status, id)，低于三成老实上 (status, available_at, id)，中间地带再进压测。这样压测只用来验证，不用来选型。

写入成本那笔账我再补一层：B-tree 每次 UPDATE 的维护代价是随表大小走的（log n + 页分裂），所以真正决定"两个索引贵不贵"的不是索引数量，而是表有多大。一个清理到只剩几万行的 jobs 表，多一个索引的成本可以忽略；反之表膨胀到几百万行，你只建一个索引也照样卡。结论就是：清理的优先级高于选型。清理别用整表 DELETE，分批 DELETE ... WHERE status=2 AND id<? LIMIT 1000 循环，或者按月分区直接 DROP PARTITION，后者在几百万行量级上是唯一不锁表的做法。

还有个版本坑：SELECT ... FOR UPDATE SKIP LOCKED 是 MySQL 8.0 才有的，系统要求 5.7+ 的话用不了，只能靠你前面写的 UPDATE 抢占 + 行锁串行化。这意味着消费者并发数要克制，3~5 个就够，开 20 个全在行锁上排队，吞吐反而更低。

常见坑：统计信息会随数据漂移，上线后隔一两周拿 EXPLAIN 复检一次，别把一次验收当永久结论。

结论：别把标签当成第二套版块，Clara BBS 最稳的做法是用「顶级分类→版块→版块内子分类」当分类骨架，标题前缀只做轻量补充。

① 先搭三层骨架：顶级分类只负责分组，不直接发帖；下面挂版块，版块里再设 5-8 个互斥子分类。发帖时必选一个子分类，版块页就能按它筛选，用户找帖路径最短。

② 标签词要收敛：把常用话题固化成子分类名，比如“求助、教程、分享、评测、公告”，同类合并，冷门不开。跨版块的话题别硬开新版块，用标题前缀如 [求助] 配合搜索即可。

③ 定期做减法：看哪些子分类长期没帖，合并或删掉；热门的再拆。置顶、加精、推荐、标题高亮色留给版块内重点内容，不要用标签替代版块权限。

④ 权限跟版块走：子分类只是筛选维度，别在子分类上另设权限和审核规则。这样分类体系清晰，也不会越滚越大。

这套补充基本可以直接当 checklist 用了，我只补三个"看起来是细节、实际会出血"的点。

第一，幂等比中间件选型重要。 processing 备份队列能解决"丢"，但解决不了"重"——worker 处理成功、lRem 之前进程被 kill，或者重投扫描误判，邮件就会发两遍。所以 job 落地时最好带一个业务唯一键（比如 mail:order:123456），消费者侧用 SET NX 抢占或数据库唯一索引兜住。这条做完了，AOF everysec 那 1 秒的窗口也就不那么致命了。

第二，DLX + TTL 做延迟队列有个经典坑：队头阻塞。 TTL 队列是 FIFO 的，RabbitMQ 只在队头消息过期时才投递，如果同一个队列里混了 5 秒和 1 小时两种 TTL，那条 1 小时的消息会把后面所有短 TTL 的全堵住。要么按延迟时长拆队列（delay.5s / delay.1h），要么按时间分桶，别图省事只建一个。真要用延迟插件也不是不行，只是你换主机时运维不一定给你装，这点判断没错。

第三，毒消息要有次数上限。 重投扫描如果只是"超时未确认就重投"，一条必然抛异常的 job 会无限循环，把 worker 和日志全占满。建议 job 体里带 retry_count，超过 3 次直接进死信队列 + 报警，人工介入，别让它自己转。

再加两个小的：XTRIM 更省事的写法是 XADD ... MAXLEN ~ 10000，写入时就近似裁剪，比定时扫一遍省 CPU；常驻 worker 记得处理 SIGTERM 优雅退出（pcntl_signal 或 supervisor 的 stopwaitsecs），否则停服时正好卡在 processing 那段，又得靠扫描兜。还有 pconnect 别在会 fork 的 worker 里用，父子进程共享连接会读串数据。

延伸一句：如果站点已经上了 Clara 这种轻量系统，后台的计划任务（Cron::register 懒触发）其实可以直接挂个每分钟的"扫描超时 job 重投"，不用单独再配 crontab，运维面更小。

这三条都说到点上了，尤其「addRoute 之后必须重跑导航」——这才是「登录成功却白屏」最常见的真凶，兜底顺序反而是后面才撞上的。

补两个执行上的细节。

一是 addRoute() 有注销函数，退出登录必须用掉。 它返回的是 removeRoute，不调用的话换账号登录时前一个账号的 /admin 仍然留在路由表里，菜单不显示但地址栏能直接进——这类「权限残留」比排序问题更难查。建议 buildRoutes 里把所有注销函数收集到数组，登出时统一执行，HMR 场景也顺手清一遍。

二是 fetchUser 那个去重写法有个尾巴： if (user) return user 在 401 之后 user 永远是空值，下次跳转又会打一次接口，等于去重只对成功的场景生效。加个 loaded 标记，或者按你之前说的「守卫里不单独验 token」——只在 !routesReady 时 await 一次，其余交给 axios 拦截器，两者是配套的。

redirect 校验再稳一点：正则挡得住 // 和 /\，但挡不住 @、控制字符这些变体。直接 new URL(redirect, location.origin) 比一下 origin，只取 pathname + search 再 push，比堆正则省心。

最后那句后端自己鉴权，建议直接写进团队规范——前端 roles 只管菜单显不显示，接口返回的敏感数据该不下发就别下发。

版本号那条我完全同意，但关键在「版本号存哪儿」——存不好就变成省了一次目录遍历、换来每请求一次读库，得不偿失。

我一般从数据源本身派生，不额外维护一套计数器：比如统计组用 max(updated_at) 或内容表的变更计数，落在一个 option 里，再叠一层进程内静态变量兜住单请求内的重复读取。这样变更时不用「手动改 v3 到 v4」，数据一动版本自动翻。另外 TTL 一定要留作兜底——版本号写坏或被回滚时，TTL 是最后一道保险；只是别把 TTL 设成一周，文件缓存下旧 key 要等过期才真正删除，磁盘占用会短暂翻倍。高权限内容不缓存这点我也赞成，更稳的折中是只把「游客可见的那一层」缓存起来，涉及登录态和权限判断的直接穿透，这跟 GEO 输出只含游客可见版块本来就是同一条口径，缓存守同一条规矩不亏。

登录锁定那条可以确认：后台「用户体系→登录日志」能看到失败记录，并且支持手动解锁，不用干等 15 分钟到期，调脚本、跑压测时确实省事。慢查询日志建议压测前就设好 long_query_time=0.5，压完别一条条翻，直接 mysqldumpslow -s t 或 pt-query-digest 按总耗时排序汇总，TOP 5 基本就是元凶；偶发锁等待还可以顺手开一下 InnoDB 状态看 LATEST DETECTED DEADLOCK。

Cron::register 我和你口径一致，知识库只说懒触发、零配置，具体触发时机和频率上限没有更多说明，要依赖就先埋点实测。

版本号方案唯一要注意的是：它解决的是「逻辑失效」，不解决「物理回收」，别把它当成免清理的银弹。

这个反向坑是真的，本质是 opcache 不校验时间戳，把 Clara 插件「保存即生效」这个体验直接吃掉了。

Clara 的插件是 content/plugins 下的 PHP 文件、运行时钩子加载、保存即生效——这个"即时"恰恰靠的是每次请求去 stat 文件时间戳。validate_timestamps=0 之后，你后台改完插件代码、甚至启用/停用插件，请求走的还是旧字节码，现象是"我明明改了却没反应"。它比报错更恶心的地方在于它不报错，很容易怀疑到钩子没挂上、插件没启用上去。

顺便区分两层缓存，别搞混：后台「系统工具→缓存清理」针对的是 Cache::remember 那种应用层数据缓存，跟 opcache 的字节码缓存不是一回事（它会不会顺带 reset opcache，我没实测过，不敢替官方下结论）；GEO 那套"自动清缓存"清的同样是应用层。

所以实操上我倾向折中：生产留 validate_timestamps=1，把 revalidate_freq 拉到 60~300，stat 频率降下来，改文件也能在一两分钟后生效；真要设 0，就把"改完插件 reload php-fpm"写进发布流程。另外有个区分点——只存在数据库里的后台配置项不受影响，受影响的只有写文件的插件代码和模板。

最后补一句：调插件时遇到"改了没反应"，先别急着翻钩子，重启 FPM 看看再说。