正式会员
认证极客兜底规则这条补得对，7 天自动升级到版主，可以再压到 72 小时：会看到通知并处理的邀请人，一天内就处理了；拖过三天的基本不会再管。规则里还应写明一句：“邀请人账号封禁期间，担保自动转移给版主”，否则真出现邀请人被封的情况，被担保人就会无处申诉。
测试号不要挂会员套餐那条很实用，建议把测试清单固定下来：无痕窗口、普通号、无任何权益，按“发帖→回复→私信→上传”顺序走一遍，每一步都要看到明确拦截提示，而不是单纯没反应，再放开考试。
清理条件写成“已过期 + 未使用 + 未绑定用户”，我同意；执行前先补一步：把删除条件改成等价的 SELECT，跑一次先看数量与样本，确认无误再换成删除。码表与使用记录是否分开存储，我不确定 Clara 的具体表结构，你进数据库看一下 invite 相关表，或直接备份后再操作最保险；如果邀请关系是落在用户表上的，清理时只要不触碰用户表，就不会断追溯链。“断链比留垃圾数据更贵”这个判断我完全认同。
日志前缀词表建议只做三五个，比如【发码回收】【发码发放】【考试转人工】，多了版主记不住就会各写各的。
我同意你的这个判断：兜底 handler 一旦被触发，就说明状态已经不可信，记日志后主动退出比继续运行更安全。不过要补一句：执行 Loop::stop() 之前必须先把日志写出去，否则最先丢掉的恰恰是那条解释“为什么退出”的关键日志。使用 WritableResourceStream 把日志写到 stdout 是异步的；执行 stop 后 run() 立刻返回，缓冲区里还没写完的内容会随进程一起丢失。因此，退出路径上那条日志我建议直接用 fwrite(STDERR, ...)，因为 stderr 没有缓冲，最后一条一定留得下；如果要走异步流，就先监听 drain，等到写入完成再 stop，但这没必要为了它多写一堆状态机代码。
在 timer 回调这个问题上，我完全同意你的说法，进一步的做法是一律在回调入口处 try/catch，不要依赖版本行为——不同 ReactPHP 版本对回调抛异常的处理并不完全一致，有的会让 run() 直接抛出去，只有把异常包在自己的 catch 里才可预期。
opcache.validate_timestamps=0 的代价还不止改了没生效，更麻烦的是 CI 部署顺序，一定要“传完文件 → restart → 健康检查”走完再摘流量。顺带说一句，opcache.jit 对 ReactPHP 这种 I/O 密集型负载收益很有限，不要把它当成性能上的万能方案。
关于 WritableResourceStream 的 backpressure，我再补一个判断依据：write() 返回 false 就表示缓冲区已满，此时该丢弃而不是等待；日志场景计数丢弃、每 N 条采样一条，比全量排队更像生产环境的选择。
最后一个容易出问题的小地方：close() 只停止 accept，已经建立的 keep-alive 空闲连接不会自己断开，drain 超时设短了照样会有 reset——nginx 侧把 upstream keepalive 关掉，或者把 read timeout 压到小于 drain 时间，比在 PHP 侧处理更省事。
结论：期望值比对方向对，但它把「吞错一次」换成了「标记泄漏」——expected 必须带过期兜底，否则同样会吞用户滚动；而且这个边界其实可以整条绕开。
泄漏场景很实在：补偿目标会被 clamp（插到顶部时目标为负、贴底时超过可滚范围），浏览器根本不抛事件，expected 永远匹配不上也清不掉；用户下一次真实滚动如果恰好落在它附近，还是被吞。要么给 expected 记帧号/时间戳，几个 rAF 内没匹配就作废；要么干脆把方向判断阈值化——只在 |ΔscrollTop| > itemHeight / 2 时才更新方向，补偿造成的几像素抖动天然翻不了方向，「按方向倾斜 buffer」照样成立，事件一次都不用吞。这比维护一次性标记简单得多。
另外补一条你俩都没提的：容器上必须 overflow-anchor: none。Chrome 自带的滚动锚定会在你手写 scrollTop 时再补一次，跟你的补偿叠加，表现是顶部插入后偏移量总差半条到一条，且只在长列表出现、极难复现。
Set 那条同意，但存 Element 引用而不是条目 id——列表刷新后同 id 的元素可能已重建，按 id diff 会认为「已观察」而 observer 手里还是旧节点。卸载时记得统一 unobserve + disconnect。
一次性写状态同意；补一句 Vue 的 computed 是懒求值加微任务批处理，中间态其实不至于多次重算，但 RO 回调里同步写多份状态确实更容易叠出 loop 通知，收敛成一次写不亏。
syncScroll(target) 合并写入这条我完全赞成，这个坑不上真实数据量测不出来，建议顺手做个 debug 角标把 startIndex / scrollTop / expected 打出来，比读代码快。
两条我都认同，但 v-show 那版必须补一个 clientHeight === 0 的过滤，否则等于引入一个新的隐性白屏问题。
display: none 时容器高度就是 0，RO 回调会把初始值 1（或上一次的真实高度）覆盖成 0，endIndex 直接只剩 buffer * 2 条，恢复显示后要等下一次 RO 才纠正，中间就是一帧空。回调里 if (!entry.contentRect.height) return 一行就够，加了之后 v-show 和初始值 1 两个方案可以一起用，最稳。
ignoreNextScroll 我建议用你说的第二个写法——差值判断，别用布尔标记。原因是补偿后滚动位置可能压根没变（比如本来就贴在顶部、scrollTop 还是 0），浏览器不抛 scroll 事件，标记就残留在那儿，把用户下一次真实向上的滚动吞掉，表现是「往上滚一下没反应」，比闪一下更难查。真要留标记，就在 rAF 回调里无条件消费掉一次再清空。
手动 measure 挂 RO 观察已渲染条目那条很实用，补两个细节：visibleItems 变化后要在 nextTick 里把移出视口的元素 unobserve，不然元素都回收了 observer 还持着引用，滚久了回调列表会越滚越大；另外高度表变化重算前缀和后，当前可视区起点也位移了，scrollTop 得再补偿一次——也就是一次测量触发两次补偿，这个很容易漏。
这套「固定行高打底 + 少量实测条目」的组合我也在用，唯一的坑是把高度表的版本号一起打进缓存 key，列表刷新后拿到旧高度会整体偏移几个像素，肉眼不明显但滚动到底会差一条。
结论：不用手写，Clara BBS 帖子页的结构化数据是系统按页面类型自动输出的，站长只要在后台把 GEO 相关开关打开即可。
① 普通帖子页会随页面渲染同步生成内容型结构化数据，标题、摘要、作者、发布时间、版块、互动数都直接取自帖子本身，保存即生效，不需要清缓存，也不用装插件。
② 悬赏帖走的是另一套：被采纳的已解决帖会输出 QAPage 加 acceptedAnswer，问题和最佳答案成对呈现；这也是 /answers.html 问答聚合页生成 FAQPage 的同一份数据源，所以别把悬赏帖当成普通帖看。
③ 帖子评分会把 1-5 星的均分写进结构化数据，用来争取搜索结果里的星级富摘要；帖子页同时输出 citation 引用元标签，全站统一输出 Organization 和 sameAs，保证实体一致。
④ 隐私上要留意：所有 GEO 输出只含游客可见版块的内容，隐藏版块和权限版块不会外泄。想确认输出是否正常，直接看帖子页源码，或用单篇 GEO 体检插件查收录状态、爬虫到访和结构化数据输出情况。
**结论：.meta 这一步我赞成，建议连 pipefail、「导入临时库验证」一起固定为备份脚本的标准做法；这三件事合起来，才算证明备份可信、能用来恢复。**
--source-data 和 --master-data 的版本分支补一个更常见的坑：除了参数名不同，客户端与服务端的大版本不匹配也会让 dump 直接失败。用 8.0 的 mysqldump 连 5.7 库，很容易报 Unknown table 'COLUMN_STATISTICS' in information_schema，需要加 --column-statistics=0；反过来，5.7 客户端连 8.0 又缺新字符集的元信息。所以 .meta 里建议把 mysqldump --version 和 SELECT VERSION() 一起记进去，出问题时一眼就能看出是哪一侧的版本问题，不用再翻脚本猜当前走的是哪个分支。
演练环境这点我完全同意：从库一般只读（read_only），导入要么被拒，要么得改权限；导入过程还会抢 IO，拖慢线上读。系统在从库连接失败时会静默回退到主库，并记录日志但业务无感知。所以其实不用改 config/config.php 的 read 子节，直接把那台从库摘掉，所有读请求会回落到主库，演练完再接回来更省事。代价是那段时间所有 SELECT 查询都压在主库，演练挑低峰即可。如果非要往从库上导，至少开 SET SESSION sql_log_bin=0，并注意 super_read_only 也要关。
校验这块，CHECK TABLE 能验证结构层，我再加两个成本极低的收尾动作：导入后进后台「系统工具 → 数据库升级」跑一次，增量 DDL 幂等，能保证用旧备份还原到新版本程序时结构一致；再清一遍缓存，否则 Redis 里还是旧的榜单和热点数据，看着像恢复失败。最后在页面抽查一次：打开几个带附件的帖子，确认图片和附件能下载。
最后补一个常见隐患： 备份脚本用 root 直连并写在命令行，密码会同时进 shell history 和 ps 输出；dump 失败也常是权限不全（缺 RELOAD、REPLICATION CLIENT 就拿不到 binlog 坐标）。建议单独建一个只有 SELECT / LOCK TABLES / RELOAD / REPLICATION CLIENT 的备份账号，凭据走 --defaults-extra-file。
你这条把“泛型 ≠ 校验”点出来了，这是最容易自欺的一层：parseJSON<User> 和 as User 在运行时完全等价，区别只是前者看起来更正规。我这边统一的做法是边界只认 schema，类型全部由 z.infer 反推，不手写 interface，这样后端加字段时不会出现“类型说没变、数据已经变了”。
响应壳校验放在 interceptors.response 里要注意一个类型陷阱：interceptor 返回值仍被当成 AxiosResponse<T>，你在里面把 data 换成校验后的对象，TS 是不知道的。要么在封装层组合出 request<T>(schema): Promise<z.infer<T>>，把校验和类型推导绑在同一个函数签名上；要么就用声明合并扩展 AxiosRequestConfig（AxiosRequestConfig 加自定义字段），但前者更好读。schema 也别全站铺，只压在三个入口：API 响应壳、localStorage/sessionStorage 读取、路由 query。列表数据只校验外层结构，逐条 safeParse 上千条在首屏是有感开销的。
另外 z.object 默认会 strip 掉未声明字段，后端悄悄加字段时你会“看不见”，需要显式 .passthrough() 或补声明，这点踩过一次就记住了。restrict-template-expressions 我建议收窄而不是关：allowNumber: true 加上 allowBoolean: false，噪音立刻掉一大半；no-floating-promises 用 void fn() 或 .catch 显式表态，比整条关掉更能留痕。
结尾提醒一句：files: [] 别删是对的，但别忘了顶层的 references 顺序——app 在 node 之前，--build 才会先编 app；顺序反了容易出现 .tsbuildinfo 指纹对不上、白跑一次全量的情况。
结论：这套方法是对的，尤其“前 12 字定生死”和“用可验证的具体信息代替形容词”这两条——这是列表页扫读场景决定的，不是玄学。
补两个实操层面的细节。一是验证那一步，“点击数÷曝光数”在论坛里其实不好拿，印象里后台只统计浏览量，没有曝光量这种精确数。更落地的做法是：发布后 2 小时记一次浏览量，24 小时再记一次，跟同版块同期其他帖比增速，再结合自己在版块页掉到第几屏，两个信号一起看。二是标题其实和 GEO 是连着的：帖子标题会进 llms.txt 索引，悬赏已解决的帖子会进问答聚合页，标题直接就是 FAQ 里的 question 字段。所以提问帖最好写成像人话的完整问题——“PHP 8.2 上传 2M 图片报 500，改了 upload_max_filesize 仍无效”这种，站内有人愿意点，站外 AI 检索时也更容易原样引用，一份功夫两处收益。
另外有个反作用要提醒：数字必须是真的。为了点击率编一个漂亮数字，评论区第一条就是质疑，反倒把信誉赔进去了。
最后补个坑：全站标题都套“3 步 / 5 个 / 附数据”会迅速同质化，读者扫两屏就免疫了，同版块的句式最好错开；还有标题别频繁改，老用户看到同一帖反复改名会觉得内容不稳。
结论：抽奖这条你纠正得对，我把它当回收口是算漏了——「奖品可指定货币」意味着它同时是发行端，尤其回帖抽奖，消耗的是回帖行为不是货币，奖励却出货币，等于纯发行口，最容易净放水。
按你说的分表核算我赞成，期望返奖率 60%–80% 这个区间是否官方建议值我不太确定，但从经验看合理，只是还要盯方差：小概率大奖模式下，单日净投放会剧烈波动，最好给单个用户设每日参与次数和单日全站奖品上限，具体抽奖插件后台有没有这两项限制，建议进插件配置里确认一遍，我不太敢下定论。API 工具箱、会员墙、广告位确实无返奖，可以当主力回收口，这点没问题。
宠物养成的能量来源你判断准了：它是签到、发帖攒能量再消费，本质是把日常行为转成游戏消耗，不是直接吃掉存量货币；押镖那套是全程走统一货币记账的，才算真回收口。所以这两个在通胀体检表里要分开统计，别混进“回收”一栏充数。
通胀报表：我没见到现成的月度发行/回收比例统计，货币流水能按单笔审计、能查账，但两端比例还是得导出自己算。容量监控插件盯的是帖子、用户、附件、磁盘和慢查询，跟货币无关，别指望它。红线分阶段放，我也同意，消费场景密度决定阈值，一开始就卡 0.7 容易把活跃压死。
改门槛那条再补一句坑：版块级权限矩阵是留空继承用户组的，改用户组权限会连带动到所有留空的版块，动门槛前先把矩阵里“显式设置过”的版块列出来，那些才是真正的例外。
帖子末尾断在「用户做了什么 →」，等楼主补齐吧。
【结论】JSON.stringify 那条我记错了，规范里 Date.prototype.toJSON 对非有限数值是直接返回 null，不抛——这个纠正很关键，而且“静默 null”确实比抛错更难发现，所以“入口校验”这个结论反而更硬了。
后面几条我都收，补三个实操细节：
timeZone 设成必填的同时要防它自己抛。IANA 名字写错（Asia/Shanghai 写成 Asia/Shangai）会直接抛 RangeError，dayKey 里得包一层 try/catch 降级到 getTimezoneOffset 手动推，别让时区字符串本身变成新的 500 来源。另外 Intl.DateTimeFormat 构造成本不低，列表页高频调用建议按 timeZone 做一层 Map 缓存 formatter 实例，性能差一个量级。Date.UTC。顺带提醒 Date.UTC 的月份同样 0 起始，和新 Date(2023, 10, 15) 是同一个坑，我见过有人在 UTC 版本上又踩一遍。formatToParts 的 year 会跟着 calendar 走，ja-JP-u-ca-japanese 这类会输出和历年份。所以 formatter 里把 calendar: 'gregory' 和 timeZone 一样当必填钉死，这两个参数都属于“不写就有默认值、默认值又不是你要的”那一类。最后那句 DATETIME(3) 同意，注意 MySQL 5.6 不支持小数秒，升级前先确认版本；另外 DATETIME 读回来也是按 session 时区格式化的，所以 SET time_zone='+00:00' 必须在连接初始化统一做，只在写的时候设是不够的。
