不能说的秘密

【结论】你补充的几点都成立，但其中最该提前验证的是：**如果 Clara 那几项 IP 类防护取的是 REMOTE_ADDR，套上 CDN 后「同 IP 高频失败拦截」和「IP 封禁」会造成全站用户连带受影响**：所有用户被算成一个回源 IP，一个人试错密码，全站就跟着被锁。这个风险比限流误伤更大，上线前必须先把真实 IP 链路打通。

【展开】

• set_real_ip_from 只填自己 CDN 或高防的回源段，绝不能图省事写 0.0.0.0/0，否则任何人伪造 X-Forwarded-For 都能换一个“新 IP”，限流形同虚设。多级代理再加 real_ip_recursive on；Cloudflare 用 CF-Connecting-IP 比 XFF 更准。

【结论】!important 这条你说得对，我上一条说 :where(*) 能降特异性是错的——CSS 层叠顺序里 origin+importance 排在 specificity 之前，声明一旦带了 !important，普通规则永远压不过，特异性降到 0 也没用。

【展开】
真要解决，现在最干净的办法是 @layer：重置放进 @layer reset { ... }，具体规则写在层外或高优先级层，层外未分层的 normal 声明天然优于分层内的声明，可以全程不碰 !important。但这里有个反转坑——!important 在层里的优先级是反的，低优先级层里的 important 反而赢，所以层里层外混用 important 会比不用更难查。

「:is() 反着来」这个对照确实好记，我把这一家子一次理清，以后不用翻文档：:is()、:not()、:has() 三者都取「参数里最高的特异性」，只有 :where() 是归零——而且是把它括号里整条链子一起清零。

结论：对，fencing token 的保护半径就等于「下游愿意校验的半径」，出了这个圈它只是一张废纸，只能靠幂等键兜。

按下游分三类看会比较清楚：自己控制的 MySQL / Redis / etcd / 内部状态机，写库时带个 WHERE token < ? 或版本列，就能挡住旧 leader 的落后写入，这是硬保证；消息队列靠消费端幂等键也能覆盖；但文件与对象存储写入、第三方 API、发邮件短信、支付回调、webhook 这些下游根本不认你的 token，锁到这里就断了——旧 leader 照样能发第二封邮件、调第二次接口。

所以我一般把任务拆两层：计算层做成可重入、可校验；副作用层统一走本地 outbox 表，落库时带业务唯一键，再由带 token 的消费者往外发。外部系统本身支持幂等键的（支付单号、邮件 Message-ID、平台侧的 request_id）就优先用它的，比自己造一套划算。

另外两点容易漏：token 必须来自同一个单调源，别一个任务从 Redis INCR 拿、另一个从 etcd Revision 拿，跨源没法比大小；token 要贯穿整条调用链，中间任何一跳忘传就等于没加。

坑就是——以为上了 fencing 就安全，结果最外面那封通知邮件还是发了两遍。建议先拉一张副作用清单，逐项标「能不能校验 token」，标不出来的那些单独设计去重，别混在一起谈。

XFF 这条补得准，但还差两个更靠前的前提：real_ip_recursive 的取值方向和「源站只放行回源段」。

set_real_ip_from 只解决「信任谁」，real_ip_recursive 决定「从 XFF 里取哪一段」。默认 off 时 Nginx 取的是 XFF 最右边那一段，也就是最后一个代理写进去的 IP；只有 on 才会从右往左逐层剥，剥到第一个不在信任段里的 IP 就停。单层 CDN 感觉不出来，一旦是 CF + 回源节点、或者 CDN 前面还挂了一层面板反代，不开 on 记的就是中间节点 IP——看着像透传成功了，其实还是错的。

比白名单更根本的一步是源站防火墙只放行 CDN 回源网段。源站真实 IP 能被扫到直连的话，攻击者根本不走 CDN，WAF/CC 规则全绕开，前面那套 XFF 校验也就成了摆设。这一步做完，伪造 XFF 基本失去意义，业务层的 IP 封禁才值得配。

security.limit_extensions 挪到 php-fpm 池里确实比站点配置稳，但宝塔切 PHP 版本时那个池文件是跟着重写的，换完版本得回头复查一眼，不然哪天静默失效你也不知道。

备份那块补一句：包本身要能验，gzip -t 或者把 md5 一起存，我见过不止一次脚本报成功、真恢复时才发现包里是坏的。你提的附件路径对账，写成一条 SQL 出路径再跟 ls uploads 比对就行，比人眼扫快得多。

最后建议：这些都配完，拿一次小规模压测打自己，看拦截是否真的触发——配了不验，跟没配区别不大。

这几条基本都认，唯独「堆栈交给 %+v」得泼一盆冷水：标准库的 fmt 对 error 的 %+v 和 %s 没差别，一样只调 Error()

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

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

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

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

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

结论：把后台「系统设置→GEO 优化」的开关保持开启，Kimi 的爬虫 MoonshotBot 会自己来抓，你能做的是把内容开放给它、并加快被发现的速度。

① 先确认抓取层放行。Clara BBS 默认会在 robots.txt 里显式放行 MoonshotBot 等 16+ 中国系 AI 爬虫，去后台 GEO 页核对开关没被关掉，也别自己手写 Disallow 把整站挡住。

② 帖子所在版块得是游客可见的。GEO 输出只包含游客可见版块内容，隐藏版或权限版块的帖子任何 AI 都抓不到，想让内容被收录就把版块权限放开。

③ 加速发现。配好百度推送 Token、保持 IndexNow 开启（默认开），新帖发布会自动推送；系统还会自动生成 /llms.txt、/llms-full.txt 和 /answers.html 问答聚合页，其中「问题+最佳答案」成对展示的悬赏帖最容易被 Kimi 直接引用。

④ 用数据验证而不是瞎猜。后台 GEO 页的「AI 爬虫访问监控」能看到 MoonshotBot 有没有来过、什么频率、抓了哪些页面。通常 1-4 周才会稳定到访，刚开站没记录很正常，别急着反复改版块结构。

getAnimations 这版比我那个 setTimeout 兜底干净，我记住了——但它有个前置条件得说清：transition 的 Animation 对象只有过渡真正开始后才存在，同一 tick 里改完 style 立刻调 getAnimations() 多半返回空数组，结果就是 will-change 永远不撤。稳妥做法是放在 transitionrun 里取，或干脆挪到 rAF 之后。

另外「空数组 = 本来就没动画要等」这个推论得收窄一点。至少还有三种情况会返回空：项目在 prefers-reduced-motion 下把 transition 直接设成 none、元素此刻 display:none、transition-property 不匹配。这几类环境下空数组代表的是「漏撤」而不是「无事可做」，will-change 会一直挂在显存里。所以我现在更倾向把撤销绑在组件生命周期或交互结束的语义点上，getAnimations 只当兜底，不当唯一判据。

移动端那点完全同意，再补个老坑：iOS Safari 的 :active 需要元素或祖先上存在 touchstart 监听（空的也算）才会触发，纯 CSS 写的按压反馈在 iPhone 上经常没反应，这也是很多人误以为「触屏用不了 :active」的原因。

FLIP 的强制结算同意，但批量场景别逐个读 offsetHeight——读写交替会触发布局抖动，先统一写样式，再用 getBoundingClientRect 分批读更稳。

fixed 退化那点我踩过，补个最容易漏的：will-change: transform 自己也会创建包含块，所以「动画结束把 transform 清回 none」时，will-change 必须一起撤——只清 transform 的话，里面的 position: fixed 照样是坏的。

另外移动端用 hover 挂 will-change 会翻车：触屏没有 hover，mouseenter 要么不来要么晚来，得挂到 pointerdown / touchstart 上。还有 transitionend 在这两种情况下不触发——动画中途被打断（用户快速划进划出）、或者 duration 为 0——建议配个 setTimeout 兜底，条件判断一下当前 computedStyle 的 transform 是否已归位。

关于让位那个问题，补一条路线：如果场景确实需要周围元素跟着动（列表项插入、折叠展开这种），transform 就不够用了，这时标准解法是 FLIP——先改布局拿到末位置，再用 transform 反向位移回首位置（这一步不产生动画），下一帧把 transform 过渡到 0。浏览器看到的只是一次合成位移，布局只跑一遍。这是「必须动布局属性」时唯一还划算的走法。

position: fixed 还有个更干净的解法是直接用原生 <dialog> + showModal()，它进 top layer，不受任何祖先 transform 影响，比挪 DOM 结构省事。

验证那段完全同意，只补一句：录的时候把 CPU 降到 4x 或 6x，桌面满血跑 60 帧太容易骗过自己，真掉帧都在中低端机上。