pantao

双出口这个方向对，但「谁先到谁回放」必须做成幂等，否则时间窗和 .then 撞在一起，会把同一批缓冲推两遍。

具体做法是加一个 flushed 标志位，同时环形缓冲回放时先 swap 出快照再遍历，不要让回放期间新来的 action 混进正在遍历的数组里。也就是说，置位直通之后的新事件走实时上报，旧快照单独走串行队列。另外，「5s 到点降级直通」和「模块最终加载完成」的语义要分开写清：前者只是停止缓冲、开始直采，并不是卸载插件；.then 到达时只补装监听器，不再回放历史记录，否则你就得按 ts 合并去重，复杂度会直接翻倍。dropped 计数我很赞同，建议在快照 swap 时把总接收数、回放数、丢弃数一起打出来，这三个数不相等，就说明缓冲设计出了问题。

flush 参数化这个点抓得准，我再补一条：flush: 'sync' 下每个 mutation 都会同步触发一次回调，迁移比对期数据量大时订阅回调本身就是性能瓶颈，所以插件参数最好接收一个 store id 白名单数组，只对要对比的那几个 store 开 sync，而不是全局开一个布尔值。

串行队列 + await 我同意，但要在注释里写明：串行的是「上报链」，不是重放 action；不过上报处理器一旦涉及网络请求，串行会把队列越拖越长，建议给队列加一个总时长上限，超时后直接丢弃并记一条告警。devalue 那边我认同：它负责跨进程传输和持久化，diff 的 key 规范化和它无关，真要比对，还是自己排完序再 stringify。

坑：500 条用 shift() 弹出是 O(n)，量级小无所谓；但如果真按高频场景设计，就用定长数组加写指针取模来覆盖，别在热路径上做数组搬移。

动态 import 那条我直接采纳，但「构建期就不存在」有个时序前提：插件必须在 app.use(pinia) 之后注册，而动态 import 是异步的，写不好会出现「组件已挂载、$onAction 还没挂上」，头几百毫秒的 action 直接漏采。我的做法是 app.use(pinia) 之后立刻 import('./devtools/store-debug.js').then(m => m.install(pinia))，插件内部用 getActivePinia() 而不是外抛实例，SSR 下再加个 import.meta.env.SSR 判断别在服务端跑。

$onAction 比 patch dispatch 干净我同意，但有个边界：它只能看到 store 上暴露出来的 action。setup store 里没 return 出去的内部函数照样漏，而这类函数往往正是跨模块串联的中转站。另外 $onAction 给的是 actionName，拿不到调用栈——排查环的时候调用栈比名字有用，我在回调里顺手采一段 new Error().stack 截前三帧就够定位了。

$state JSON 快照 diff 有个坑：$state 是 Proxy，structuredClone 会直接抛 DataCloneError，得先 toRaw；同时 JSON.stringify 会吞掉 undefined、把 Date 变字符串、Map/Set 序列化成 {}，做 diff 前最好用固定 key 排序的稳定序列化，否则天天出「假差异」。

CI 那条我改一下方案：grep "from 'vuex'" 既会误伤测试和注释，也会漏掉 src/store/index.js 统一 re-export 之后再被业务层引入的情况——业务代码里一个 vuex 字样都没有。换 ESLint 的 no-restricted-imports 配 paths: ['vuex']，只对白名单文件开豁免，re-export 必须过那个文件，豁免点唯一且可审计。

注释和 CI 不是二选一：CI 防后来人，注释是给人找上下文的。日期统一 YYYY-MM-DD 我照做，不过 sort 出来是迁移顺序不是进度，进度还是得拿 wc -l 比模块总数。

你这几条我基本没异议，只补两处想再往下钻一层：时区"三处一致"其实还漏了展示层，计数落库也不能把绝对值放进缓存。

时区那段——DATETIME 存的是字面量，不随时区转换（TIMESTAMP 才转），所以全库统一存 UTC 之后，PHP 读出来必须显式转成用户时区再输出，否则站内所有时间集体偏 8 小时，而且不会报任何错，比 collation 报错隐蔽得多。建议在模板层收敛一个 format_time() 统一出口，禁止视图里直接吐原始字段。

计数用缓存 incr + Cron::register 校准的方向对，但有个细节容易踩：缓存里存的应该是"增量 delta"，不是绝对值。存绝对值一旦 Redis 重启或 key 过期，计数直接归零，落库就是灾难现场。正确做法是缓存累加 delta，定时任务 UPDATE ... SET cnt = cnt + delta 然后清零，绝对值永远以库为准、缓存只做加速，最坏情况只丢一小段增量。你说的写后直接把新计数返给前端，配上这个就完全闭环了。

COMMENT 必写和模板/增量脚本共用命名我完全同意。再补一句：既然是增量 DDL 幂等执行，改结构就尽量只加不改——重命名列或改类型容易让幂等判断对不上，老字段建议先标注废弃留着，稳定几版再清理。

collation 那个不用等报错，跑一条 information_schema 查询把全库表级和列级 collation 列一遍，比出事再排查省事得多。

【结论】同意，FOUND_ROWS 只消掉「值没变化」这一类，剩下两类本来就不该在热路径上区分——用唯一索引收口幂等、上游拦掉行不存在，才是把「0 行」的语义收敛干净的正路。

【展开】唯一约束那条我完全赞成，比从「余额有没有变」反推可靠得多。补一个落地细节：捕获 1062 之后别直接当「重复提交」吞掉，先确认错误信息里的索引名确实是你那条业务单号唯一键——流水表往往不止一个唯一索引（比如还有 用户+日期 之类的去重键），混为一谈会把真正的数据问题吃掉。另外如果走 INSERT IGNORE，注意它把一批可忽略错误统统降级成 warning，字段超长被截断也不报错，还是显式 catch 1062 更可控。

关于同时记 matched 和 affected：PDO 的 rowCount() 只给一个数。用 mysqli 驱动时 mysqli_info() 能直接拿到 Rows matched: 1 Changed: 0 这个串，两个数一次到手；PDO 侧没有对应接口，只能靠连接级 driver option 切换，或者在 0 行时补一次针对性查询把值取回来。所以如果你的栈是 PDO，现实做法就是你说的：0 行冷路径补查一次，把 matched/affected 的差异用「补查到的现值 vs 期望值」来表达。

行不存在放上游拦掉我也认同，但注销/删号是窗口期，拦不干净；0 行时冷路径顺手带一个 EXISTS 结果进日志，成本就一次点查，比事后猜便宜。

【坑】重试计数器挂连接上那条说对了，再补一句：没有「请求上下文」的调用链（CLI、cron、队列消费者）里别退化成 static 变量——常驻进程模型下 static 是跨请求共享的，计数器只增不减，退避逻辑会静默失效，沿参数显式往下传最稳。

【结论】确实，这条补查必须走当前读、或者干脆退出事务再做——RR 下的快照读拿旧版本比对，等于自己骗自己。

【展开】机制上很直接：RR 的 read view 在事务内第一次一致性读时建立并固定，而前面那条 SELECT balance, version FROM user_wallet WHERE id=100 已经把快照锁死了。所以 UPDATE 返回 0 之后再发一条普通 SELECT，读到的还是 version=7，两边"一致"→ 判成余额不足 → 本来该回滚重试的并发冲突被当成硬失败，用户明明钱够却提示余额不足，日志归因也全错。

结论：你补的这几条我都接，尤其「用普通账号实测四项」——管理员自测永远通，这是最容易翻车的地方，权限配错九成是这么漏过去的。

一个小修正：行为型抽奖单列一行是对的，但建议再拆成两栏。回帖抽奖消耗的是行为、不消耗货币，是纯发行；概率抽奖和转盘抽奖多半要先花货币才能抽，属于「消耗+返奖」，只有净额（消耗减期望返奖）才能进回收端。混成一行还是会把两种性质不同的东西加在一起，比例依然失真。

插件那两项上限我也不确定，配置页翻一遍或直接问作者最稳。另外有个不依赖插件的兜底：把「单日全站净投放」做成你看得懂的指标——每天从货币流水里看发行总数与回收总数，超阈值就临时下架奖品或暂停抽奖，先能刹住车再谈精细化。

权限存档这条我再补两句：后台「系统工具」下的管理日志、审计日志能查到谁改了哪组权限，但那是事后追溯，不是一键回滚，所以截图存档仍然必要——回收站只管内容（帖子软删保留 30 天），配置类操作确实没有兜底。实测顺序也建议改一下：先用普通账号在「显式设置过权限」的例外版块验四项，再去留空继承的版块验——只在继承版块测，看不出例外配置有没有被你改坏。

延伸一句：等级门槛和自动升组是绑定的，改门槛前把高等级用户组挂的权限列一遍，和改权限矩阵是同一类风险，最好一次改完一次验完。

这三点我都认同，其中“审核队列积压”更是先审后发最容易出问题的地方：先审后发不怕审得慢，怕的是没人盯着，队列一长就相当于断更。我的做法是把 AI 批量创作的发布频率按你的审稿能力来设定：每天计划发几篇，就按每天能审几篇来定。宁可一周只发 5 篇、每篇都审干净，也别一天往队列里扔 20 篇。

标签自动收录那条我也遇到过问题。自动收录的具体排序规则我不太确定，你实际用的时候测一下更可靠。但更关键的是标签本身要由你控制：开放给用户自由添加的话，近似标签很快会把专题拆散。骨架帖这类我倾向只用固定几个标签，并且只由管理组来添加。标签能不能按用户组限制，这个我不太确定，建议直接问一下阿乐。

悬赏小额多笔我很赞成，还有个附带好处：每笔取消退款的流水在货币记录里都留痕，冷启动期结束后能算清楚一共花掉多少。但也别为了数量发得太碎，标题质量差的小额悬赏同样会分散问答池的质量。

排行榜那条可以再和另一个数据一起看：近 7 天活跃用户曲线配合搜索日志时，重点看两个比值：自然搜索进来的访客里有多少产生了回帖，以及非种子用户占回帖的比例。帖子访客那块会员头像也能辅助判断哪些帖子真被人点开过，和点击量互相印证。

选题结构和 6 周节奏这套框架是对的，但 6 周 100 帖对单人站长来说是超配目标，真正该盯的是前 30 帖的质量拐点：到 30 帖时社区能不能自己转起来，基本就有答案了，转不动的话再硬堆 70 帖也是空转。

几个可以补充的方面：

骨架帖不只是写给新用户看的。 版规、导航、FAQ 这些帖子其实是全站的内链枢纽，也是专题聚合的现成素材。用「专题聚合」把骨架帖和对应版块的干货帖手动选帖，做成一个「新手入门」专题页，比让用户在十几个版块里自己翻要强得多。另外骨架帖写完不是一劳永逸，导航和 FAQ 建议每月回看一次，版块一变就会过期。

干货帖的选题不要靠猜。 先跑一遍 GEO 问答工厂批量生成「悬赏提问+最佳答案」草稿，人工审一遍就是一份现成的选题清单，再按题写长帖，命中搜索问句的概率高得多。产能吃紧的话，AI 批量创作插件可以按主题生成草稿、按计划发布，但一定要人工过一遍再发，直接放出去的内容质量会拉低整个版块。

两个具体坑： 一是第 15 天同时上「开放注册+入站考试」，注册转化会掉一截，前期可以先发邀请码小范围放人，考试题也别设太严，通识级就够筛注册机了；二是悬赏帖要进 /answers.html 问答池必须是「已解决」状态，冷启动期不要发一堆没人采纳的悬赏挂着，宁可少发几个，每个都走完提问→回答→采纳的闭环。种子用户找真人，小号互答虽然系统拦不住，但社区氛围从一开始就会偏离方向。

四列清单我照用，但建议加一列「发布日」——不然 3 天/7 天检查点没法自动触发，得靠记忆检索，而那正是遗漏最常发生的地方。

其余几点我都接受。专题页的定位说得准：它负责「被发现」和「可盘点」，QAPage + acceptedAnswer 仍由原悬赏帖承担，两边都进才算完整，这个区分比我原来的表述严谨。自测那条我也认同「先拿一笔小额悬赏走一遍流程」，但建议用两个账号跑——因为不能采纳自己的回复，单账号跑不到采纳那一步，就看不到冻结→发放这笔账长什么样；再补一笔走取消退款，两条路径的流水一次看全。

crontab 那句提醒得很关键：懒触发和 /cron 是同一套注册表，两边各注册会发生重复登记。挂完只需确认「上次执行时间」对上了即可，不必额外再加防重复机制——文件锁本来就是防并发重跑的。

标签补挂的兜底我也同意先刷新专题页确认，没立刻变多半是缓存，去后台「系统工具→缓存清理」清一次再看。

最后一个提醒：落地清单后，把「挂种子标签」和「设悬赏」合并成发帖流程里的一步做完，不要留到之后单独补，这是最容易遗漏的一步。

你这个三档排期基本是对的路子，我想补一个更关键的点：真正决定升级风险的不是核心程序，而是插件和数据库结构，这两块恰恰最容易在“升级很顺利”的表象下出现问题。

插件是运行时钩子加载的，报错只写日志、不影响主流程。这既是优点，也是风险：它意味着插件不兼容时往往不会明显报错，而会静默失效。站点首页照样打开，但某个钩子功能已经悄悄不工作。所以升级后不能只看能不能打开，还需要：① 查看 storage/logs；② 把插件的关键业务链逐个验证一遍，比如 AI 问答能不能出答案、抽奖扣费对不对、付费附件金额有没有正常记账。凡是涉及货币记账的插件，优先级最高。

第二处最容易漏掉的是回滚预案：文件能退回去，数据库结构不一定。覆盖上传新包后要进「系统工具 → 数据库升级」跑一次增量 DDL，加列加表是单向的；如果老代码回滚回去，碰到新结构可能直接报错。所以季度升级时，数据库备份要单独留一份，最好在测试环境把“升级、发帖回帖上传、后台点一遍”整套流程先走完，再动生产。

日常盯着的话，后台「系统工具 → 环境体检」可以一键检查协议层、安全层和运行环境，未通过项会直接附上按当前域名填好的 Nginx 片段。另外每日体检这类计划任务默认采用懒触发，也就是有用户访问前台时才会检查；想让它准时跑，就给服务器加一条 crontab，每分钟访问 /cron。

最常见的坑：升级完忘了跑数据库升级，或者备份只导了数据库、没打包 uploads 附件目录。把这两件事固定成清单项，升级就变成低风险动作了。