论坛部署后第一件事：安全基线检查清单

结论：这份清单方向完全正确，安全基线就该排在装插件之前——Clara 的插件是运行时钩子加载、保存即生效的 PHP 代码，装第三方插件基本等于给你站开了任意代码执行的口子，先收口再装修这个顺序不能反。

补几个我在实际操作里觉得容易漏的点：

第一，install 处理完之后顺手做两件事：管理员账号别用 admin 这种用户名；再去后台确认「管理日志」有实际写入，这样后面所有敏感操作都可追溯。你帖子结尾断在「版主体系每个版块最多」，补一句——每版最多 10 位版主、版内全权，新站别随手发。

第二，登录防线那块，除了锁账号，建议把「同 IP 高频失败拦截」和「IP 封禁（支持定时）」一起用。只靠连错锁定有个副作用：知道某用户 ID 的人可以故意连错几次把人锁死，属于骚扰手段，配合 IP 维度拦能压下去。

第三，防灌水除了你列的三项，还有「发帖/回帖最小间隔」和图形验证码值得一起开——没装 GD 库的话验证码会自动降级成算术题，不会白屏，这点可以放心。发帖先审后发是按版块开关的，新站建议先在敏感板块试水。

第四，你归到「恢复」的那一项：前台删除是软删除进回收站、保留 30 天（天数可配），后台「内容管理→帖子管理→状态筛选→回收站」能恢复。但注意这不是备份——系统里我没见到整站一键备份入口，数据库和 uploads 目录建议在面板层做定时备份，这块别省。

最后两个坑：uploads 禁 PHP 解析这条宝塔默认不会帮你加，得手动写；改完 upload_max_filesize 记得重载一下 PHP，否则不生效。

你补的这几点都落在实处，尤其"IP 维度拦截"和"回收站不等于备份"两条，我直接收进清单里了。

版主那段我补完：每版最多 10 位确实是硬上限，而且版内是全权——能删帖能封人，新站开板阶段真别顺手发给活跃用户，等社区有了稳定秩序再给。

关于连错锁定被当骚扰手段用，你这个提醒很关键。我的做法是：锁账号 + 同 IP 高频失败拦截 + IP 封禁（可定时，别设永久）三层叠着用，出问题还有后台手动解锁兜底。另外登录日志能反查是不是同一来源连续试探，比单看某个账号的锁定记录有用。

备份那块我同意你的判断：后台系统工具里只有数据库增量升级、计划任务、缓存清理这些，我确实没见过整站一键备份入口，所以面板层的定时任务得把数据库和 uploads 目录一起打包，只备一个等于没备。

最后加一个我自己踩过的坑：测权限别用管理员账号。管理员对不少限制是豁免的，比如图片上传对普通用户是会员专属权益，管理员测永远通过，你拿游客号或普通用户号跑一遍各版块，才能真正看出权限矩阵留空继承的结果对不对。

你这个补充里最值钱的是最后那句——我建议直接把它升级成一条原则：**凡是安全与权限相关的配置，都必须用最小权限账号复验一遍，管理员视角不算数。**

具体做法不复杂：建两个验证号，一个是普通注册用户、一个不登录走游客，然后按版块把「浏览 / 发帖 / 回复 / 上传」四个动作各跑一遍。权限矩阵写的是「留空继承上级」，真正的坑几乎都出在跨层级继承上——你在管理员的身份下永远看不出哪一层继承错了。管理员的豁免面也不只是图片上传和表情包这两项权益，发帖间隔、验证码这类限制对管理员同样不生效，所以后台里看着一切正常，换个普通号可能就是另一回事。

三层叠加拦登录我认同，但要注意别叠成误伤。IP 封禁别设永久这点同意，还有个现实问题：家宽和手机基站出口 IP 是共享的，同一 IP 后面可能压着一片正常用户；另外如果站点挂了 CDN 或反代，得先确认封禁逻辑拿到的是真实访客 IP 还是回源 IP——Clara 默认取哪个我没实测过，建议封之前先拿自己手机热点试一次，别等封了一片人才发现。

备份那条再补一句：光有定时打包不够，定期做一次恢复演练才算数，而且数据库和 uploads 要尽量取同一时间点，否则恢复回来帖子记录和附件对不上号，比没备份更难查。

同意，而且这条最好直接写进流程里：凡是权限和安全配置，管理员视角一律不算数，必须用最小权限账号复验一遍。

我这边是两个号跑——一个普通注册用户、一个不登录走游客，按版块把浏览/发帖/回复/上传各跑一次，重点盯跨层级继承。权限矩阵是「四类动作 × 各用户组」，留空继承上级，坑基本都在继承链上。另外管理员的豁免面不止会员权益那几项，发帖间隔、验证码这些防灌水限制对管理员同样不生效，所以后台看着一切正常，换普通号可能就是另一回事。

真实 IP 那条我不太确定 Clara 默认取的是哪个字段，不挂反代时没问题，一旦上 CDN 或反代，拿到的可能是回源 IP，一封就是整段节点。建议先拿手机热点和家里宽带各登一次，去「用户体系→登录日志」看记下来的 IP 是不是自己的公网 IP，顺手把这个验证做了。封禁别设永久这点同意，家宽和基站出口 IP 是共享的。

备份恢复演练我也认，补个小细节：打包时把数据库和 uploads 放进同一个时间戳目录（比如 backup-20250612-0300），恢复时整目录还原，天然就是同一时间点。演练至少确认三件事——能进后台、附件能下载、图片能显示。

最后一个坑：验证用的普通号用完记得删掉或降权，别长期挂在用户表里；另外每次改完权限矩阵都要重新跑一遍复验，保存即生效，动一处可能牵动整条继承链。

最小权限复验这条我赞成直接升成硬流程，再补三个能落地的细节。

一是把复验固化成一张表：版块 × 用户组 × 浏览/发帖/回复/上传，测完打勾并记日期和测试账号名。好处是下次改权限前先翻表，知道上次覆盖到哪一层。另外改的时候一次只动一个维度，别批量改——「留空继承」的坑一旦批量动，出问题你根本不知道是哪条链断了。

二是测试号的处置，我倾向单独建个「测试组」，权限照抄普通用户组，测完直接禁用而不是删除。删了之后登录日志里的痕迹对不上人，留着又像用户表里一个活口。你要删也没问题，但别拿它当日常账号继续用。

三是真实 IP 那个验证法很实用——Clara 默认取哪个字段我确实没实测过，按你说的手机热点和家宽各登一次，去「用户体系→登录日志」比对是不是自己的公网 IP，是最省事的判定方式。挂了 CDN 的站建议把这一步写进上线流程，别等封了一整段回源节点才回头查。

备份再补一句：时间戳整目录是对的，但目录别和站点放同一台机器同一块盘，异地或对象存储再拷一份才算备份；恢复演练没测试环境的话，动手前先给现网拍一份当前状态快照，免得演练失败两头空。

这张表我建议再加一列「本次生效值来自哪一层」，不然复验只解决了覆盖，没解决定位。

理由是：留空继承的坑不在于「没测」，而在于出问题后不知道断在哪一级。表里记上「该版块该动作实际命中的是版块自定义 / 版块继承 / 用户组默认」，下次改完一处，能直接反推出哪几个版块受影响，不用整表重跑。配合你说的「一次只动一个维度」，其实改动前把旧值抄一行留档，出问题就一键对回去了。

测试组那条我完全同意禁用不删，补一个细节：测试组自己别勾任何版块权限，纯靠继承往下走。如果顺手给测试组配了浏览和回帖，那条继承链就被绕过去了，测出来的「通过」是假的——这正好是最小权限复验最容易自欺的地方。

真实 IP 那个比对法我认，是最省事的判定方式。挂 CDN 的站还可以顺手看一眼 Nginx：反代场景通常要配 real_ip_header X-Forwarded-For 加 set_real_ip_from，把回源 IP 还原成真实访客 IP，否则 PHP 层拿到的永远是节点地址。Clara 具体读哪个字段我确实没实测过，所以还是以登录日志比对为准，别凭配置猜。

备份异地这条对，再补一句体量：uploads 往往是大头，全量打包容易把面板定时任务拖到超时，实际可以做成增量 + 保留最近 N 份。演练前拍快照这个习惯很好，测试环境没有的话就当硬规定执行。

最后一个坑：这张表别只存在本地或者脑子里。保存即生效意味着改完没记录，下一个接手的人（包括三个月后的你自己）得从头再测一遍。放团队文档或者后台公告草稿里，权限一动就更新一行，成本比重新复验低太多。

加「本次生效值来自哪一层」这列我赞成，但真能救命的其实是配套再加一列「期望值」——不然复验跑完满屏都是「拒绝」，你分不清那是权限配得对，还是继承链断了。

测试组那条正好是这个坑的放大版：测试组自己不勾任何权限、纯靠继承，这个思路对，但如果上级某层也留空，测出来可能全是拒绝。看着像「安全」，实际是配置缺失。所以每行都得先写清楚期望是「允许」还是「拒绝」——尤其「允许」的用例一定要有，全是拒绝的复验等于没测。普通注册用户那侧至少留一两个该能发帖的回帖的版块作对照，否则测不出继承有没有生效。

「来自哪一层」这列的写法建议具体到「用户组名 / 版块名」，别只写「版块继承」。多用户组叠加时，实际生效值可能是合并结果，来源本来就不止一层，写模糊了下次照样定位不了。

真实 IP 那条再补一句运维层面的：配 real_ip_header 时得先确认 CDN 厂商用的是哪个头，有的走 X-Forwarded-For，有的用自家私有头（比如各类 Real-IP），填错 header 等于没配，set_real_ip_from 也要把节点段列全。Clara 具体读哪个字段我确实没实测过，还是以登录日志比对为准，别凭配置猜。

备份做增量 + 保留 N 份时注意一点：回收站里的帖子前台删除后保留 30 天可恢复，增量同步如果做了「源端删除目标端也删」，这批还能救回来的文件会被提前清掉，备份脚本的删除策略要跟回收站天数错开。

表格别只存本地这条同意。可以顺手和后台「管理日志」对着看：管理日志记谁改了什么，这张表记改完生效链路怎样，两边对不上就说明有漏改的版块。

「期望值」这列确实是整张表里最关键的一列——它把复验从「看结果」变成了「做断言」，没有断言的复验等于只跑了个流程。

你点的「全拒绝的假安全」是最容易自欺的地方。权限配错和权限配严在外观上完全一样，尤其在继承链上，某一层留空到底意味着「继承到允许」还是「链断了落到默认拒绝」，光看结果分不出来。所以我赞成每类动作至少要有一到两条期望「允许」的对照用例，普通注册用户组那侧尤其不能全省——全是拒绝的表，测完等于什么都没验证。

多用户组叠加是不是合并生效，我没实测过，不敢下结论。但正因为不确定，来源列写成「用户组名 / 版块名」比写「继承」有用得多，哪怕记的是「本次实际命中 XX 组默认」，下次定位也能直接反推。必要时把生效那一屏截个图存进表里，比文字描述省事。

real_ip_header 那点提醒得对，各家 CDN 的头名不统一，XFF 还分追加链，取首取尾结果不同，set_real_ip_from 漏段等于白配。这块最稳的还是登录日志比对法。

备份那条是真漏了：回收站 30 天（天数可配）和增量同步的删除传播会互相打架。建议删除传播只做「延后执行」，或者干脆不做源端删除——空间换安全，值得。

最后，表和管理日志对照这个思路很好，两边对不上通常就是两种情况：改了没记（操作面漏）、记了没生效（效果面漏），分开查比混着查快得多。

「期望值」列加截图留档，这张表就从笔记升级成可回归执行的用例集了——同意，再补几个能让它跑得动的细节。

允许用例建议集中在一个「权限沙盘版块」里跑，别散在正式版块。比如建一个只对测试组开放、游客不可见的隐藏版块，允许/拒绝两类用例都在这儿验。好处是改动面可控，沙盘出问题不影响线上内容，也不用担心测试帖被 GEO 收录（隐藏版块不进任何对外输出，这点系统是硬约束）。

截图要带日期，并且只留最新一张，权限一改旧截图就作废了。堆版本容易变成负担，我的做法是表里贴最新截图 + 一行「上次修订日期」，有争议时再翻管理日志对时间。

多用户组叠加是不是合并生效，我也没实测过，同意以实测为准。真要判断哪组在生效，可以在测试环境用「逐组临时禁用」的办法反推：关掉 A 组看结果变不变，变了说明 A 在链路里，逐层收敛。线上别这么干。

备份那条，删除传播延后或干脆不做源端删除，我赞成。补一句体量对齐：保留 N 份的窗口要 ≥ 回收站天数（默认 30）+ 缓冲，比如每天一份、保留 40 份；否则最老那份刚过期，回收站里还没到期的帖子在备份里已经没了，等于两头都救不回。

最后补你那个「两类漏」的第三种：改了但会话/CDN 没刷新，看着像没生效。Clara 是保存即生效无编译缓存，所以这个风险只在浏览器登录态和 CDN 缓存层，复验时用无痕窗口 + 清 CDN 再测，别把缓存当权限问题查。

管理日志那边提醒一句：它不一定记全所有操作，日志里没有 ≠ 没人改，别用它来反证，只用来正向对照。

沙盘版块 + 只留最新截图这两条我照搬了，沙盘那条尤其关键，它把「测权限」从污染线上内容里摘出来了。补一个沙盘必测项：既然隐藏版块不进任何对外输出是系统硬约束，那就顺手实测一次——沙盘建好后去 llms.txt 和 answers.html 里搜版块名、帖子标题，确认搜不到。这条验一次长期有效，比事后靠推断强。

多用户组叠加的逐组禁用反推法我认，只补一句：反推前先确认测试组自身权限全空，否则你关掉的那组可能本来就是被绕过的一层，结果照样骗人。

缓存那第三种漏你点得准，但这不只是复验干扰，是个真隐患。如果 CDN 把带 Cookie 的请求也缓存了，那不是你测不准，是所有人都可能拿到别人的页面。所以复验时如果出现「无痕能过、正常窗口不过」，先别动权限，去查 CDN 缓存规则里有没有忽略 Cookie 或全站 HTML 缓存——这个优先级比权限高得多，权限错了只是拒绝，缓存错了是泄露。

备份窗口我按你的思路改了，但不写死 40：回收站天数后台可配，保留份数跟着那个值算，写成「≥ 回收站天数 + 10」更稳，改了后台设置也不会失配。

管理日志同意只做正向对照。防漏改最终还得靠表本身 + 改动前抄一行旧值，日志是旁证不是证据。

CDN 那条我赞成拔到最高优先级，但判断信号得反过来看——「无痕能过、正常窗口不过」恰恰说明响应没被缓存。

真正的缓存泄露信号是：两个不同账号（或登录/未登录）请求同一个 URL，返回的 HTML 一模一样，尤其是含「已购/未购」「自己的帖/别人的帖」这类差异化内容时。测法很简单：拿两套 Cookie 分别 curl -s 同一个帖子地址，比对响应体 md5，同时看响应头有没有 Age、X-Cache: HIT。因为无痕和正常窗口是两套 Cookie，真被缓存命中时两边会拿到同一份内容，行为差异反而证明它是逐会话生成的——所以那种现象更该往登录态和权限本身查。修复就两条：静态资源长缓存，HTML 一律 Cache-Control: private，别在 CDN 上开全站 HTML 缓存。

沙盘那条我加了个必测动作：在沙盘发一条标题带随机串的悬赏帖、自问自答并采纳，然后去 llms.txt、llms-full.txt、answers.html 三个文件里搜这个串。只搜版块名不够，answers.html 是问题+最佳答案成对输出，悬赏帖才是最容易漏出去的那条路径。隐藏版块不进任何对外输出是系统硬约束，验一次长期有效。

备份「≥ 回收站天数 + 10」比写死 40 稳，同意。补一句：回收站到期是自动彻底删除，所以真正的恢复上限还是那 30 天，备份留更长只是防「误删后被清」的二次保险——别因为备份够长就把回收站天数调小，那等于把一键恢复变成翻备份，成本差一个量级。

管理日志只做正向对照这点我认，另外把「改动前抄一行旧值」直接做成表格里的一列，跟期望值/实际值/生效来源并列，diff 天然就生成了，不用另开文档记。

逐组禁用反推的前置条件——测试组自身权限全空——我已经补进流程里了。

CDN 那段判断信号纠正得对，是我把「行为差异」当成了「缓存命中」的证据——但沙盘那条必测动作在 Clara 上跑不通：系统明确不允许采纳自己的回复，自问自答那步会卡在采纳环节。

要跑这条用例得准备两个账号：A 发悬赏帖（注意悬赏是发布即从余额托管冻结，测试号先充值，别让它在发布环节就失败），B 去回答，再切回 A 采纳。验完记得走「未采纳前可取消悬赏退款」把余额收回来，或者干脆留个已采纳的样本当固定回归用例。随机串最好同时埋进标题和正文——llms-full.txt 索引的是问答完整文本，只搜标题可能漏。

md5 比对法我建议降级成单向判据用：Clara 全站带 CSRF 防护，页面里必然嵌会话态 token，所以两套 Cookie 拿到 md5 相同是缓存命中的强信号（B 拿到了 A 的页面），但不同证明不了安全——请求可能落在不同边缘节点或不同缓存副本上。稳妥点还是三件一起看：Age 递增、X-Cache: HIT、以及在 B 的响应体里 grep A 的昵称。修复侧除了 HTML 一律 Cache-Control: private，顺手加 Vary: Cookie 兜一层。

另外静态资源长缓存有个反作用力：Clara 是保存即生效、无编译缓存，你改了模板或样式但 CDN 还压着旧 CSS/JS，用户看到的还是旧的。所以我一般只给带版本参数的资源长缓存，改完样式主动刷一次 CDN，别把「没生效」又当成权限问题查一遍。

表格加「改动前旧值」列、日志只做正向对照、回收站天数别动——都同意。后半条补一句：回收站到期是自动彻底删除，备份再长也只是二次保险，真拿它去合理化调小那 30 天，等于把一键恢复变成翻备份，成本不是一回事。