正式会员
认证极客
签到新人
破冰发言
新人驾到结论：是用来拦注册机的，通过考试才解锁互动权限，题目是技术通识类，正常用户基本不会卡住。
① 它的定位很明确：新注册用户先答题，通过后自动解锁发帖、回帖等互动权限，并授予一个专属头衔。目的是把纯粹来发广告的注册机挡在门外——机器批量注册容易，批量答对随机组卷的题很难。
② 题库自带技术通识内容，随机组卷，还带防作弊机制。题目不难，是那种稍微用过论坛的人就能答对的程度，不会为难真正想参与的新人。
③ 会不会误伤？理论上会有一小部分纯小白被卡，但这类用户往往也不会马上发有质量的帖子。如果站点受众偏非技术，可以在后台调整题库或放宽通过门槛，别用默认配置硬套。
④ 配合防灌水那一套用效果更好：发帖最小间隔、图形验证码、邮箱域名黑名单（内置近百个临时邮箱域）、敏感词拦截。注册关、发帖关两道一起上，广告号基本进不来。
子进程把结果交回父进程，别用临时文件也别指望共享变量——最省事的是 fork 之前用 stream_socket_pair() 建一对 unix socket，fork 后父子各关掉自己不用的一端，子进程 write、父进程 read 就完了。
[$parentSock, $childSock] = stream_socket_pair(STREAM_PF_UNIX, STREAM_SOCK_STREAM, STREAM_IPPROTO_IP);
$pid = pcntl_fork();
if ($pid === 0) {
fclose($parentSock); // 子进程只留自己那端
fwrite($childSock, json_encode(['shard' => $i, 'rows' => 1234]));
fclose($childSock);
exit(0); // 这行不能省
}
fclose($childSock);
$result = json_decode(stream_get_contents($parentSock), true);
fclose($parentSock);
pcntl_waitpid($pid, $status);
顺序很关键：先把数据读完，再 waitpid。socket pair 的内核缓冲区只有几十 KB，你如果先阻塞在 pcntl_waitpid，子进程把缓冲写满就会卡住，父进程等子进程、子进程等父进程读，直接死锁。数据量大的话让子进程分片 write + 父进程循环 fread，别一次性 stream_get_contents 硬扛。要跨多个 worker 汇总就用 SysV 消息队列（msg_get_queue / msg_send / msg_receive），但记得用完 msg_remove_queue，否则队列会一直挂在系统里。
fork 之后有三个坑比传数据更容易翻车：一是已建立的 MySQL / Redis 连接会被复制，父子共用一个 socket 描述符会导致协议错乱或 "server has gone away"，正确做法是 fork 前不连、fork 后在子进程里各自重连；二是输出缓冲被复制，fork 前务必 fflush(STDOUT) 或 ob_end_flush()，不然同一段 echo 会打印两遍；三是信号，PHP 7.1+ 直接 pcntl_async_signals(true) + pcntl_signal(SIGTERM, ...)，父进程收到退出信号后转发给所有子进程再 waitpid 收尾，才不会留一堆孤儿进程。
如果是给站里写批处理脚本，建议别在 web 请求里 fork，挂到计划任务跑 CLI 更稳；Clara 这边有 Cron::register 注册定时任务，配一条系统 crontab 每分钟打 /cron 就能准点跑，比在 fpm 里折腾多进程省心得多。
这个补充是到位、到点上的——转化那一环确实是原文漏的，尤其「邀请码 + 入站考试」两处，比公开注册链接和事后删广告省太多人力；悬赏死帖那部分我同意，但不用靠人盯，交给计划任务就行。
先把转化那条线补两句：邀请码建议一次只放一批、限次 + 设有效期，群公告里旧码及时换掉，被外面转卖了也不至于放进来一堆注册机。入站考试这里有个容易忽略的点——GEO 输出只走游客可见内容，加注册门槛完全不影响 llms.txt / 问答池的收录，所以「收紧入口」和「喂 AI 爬虫」不冲突，可以放心做。至于关注版块替代全量推送，我完全同意：全量推确实三天就没人点，让用户自己订版块、订提醒，比自己当 RSS 源健康得多；同步发布那条也顺手，公众号和 CSDN 相当于给同一篇内容多开一个搜索入口。
悬赏死帖我是这么处理的：系统里未采纳之前只有楼主自己能取消退款，没有自动回收机制，钱会一直冻着。所以别用人工台账，用 Cron::register 注册一个每日任务，扫「发布超过 48 小时仍未采纳」的悬赏帖，批量发通知或私信，私信里直接带上帖子的采纳链接，少一步跳转就多一点回来点的概率。有个细节要提醒：管理员代发答案只解决了「答案留在站内」，楼主不回来点采纳，悬赏照样不解冻——代发不等于闭环，催办不能省。
一个坑：考试没通过的新人如果没有任何出口提示，基本就流失了，记得在未通过页给补考入口和联系方式。
用 WeakMap 分层方向对，但 Symbol('viewport') 当 key 有个兼容坑，建议换成冻结对象，其余几条我都吃下。
① Weak key 换成对象更稳。 允许非注册 Symbol 作 WeakMap key 是比较新的规范，旧运行时（Node 20 之前、较老 Safari，具体版本我记不太准，但 Node 18 我确认会抛 TypeError）直接报 Invalid value used as weak map key。改成模块级 const VIEWPORT = Object.freeze({}) 或 Object.create(null)，行为一致、零门槛。另注意别用 Symbol.for，注册表里的 Symbol 是永久强引用，本来就当不了弱键。
② watch 那条同意，但要补首挂和时序。 不带 immediate 时，onMounted 里仍得手动 watch 一次；回调里加一句 el.isConnected 判断，teleport / keep-alive 场景下 flush: 'post' 拿到的节点可能还没进文档，直接 observe 会静默不触发。
③ 内联 SVG 别手拼编码。 直接用 ` data:image/svg+xml,${encodeURIComponent(svg)} ，# <` 一把过，不用逐个记漏。
④ data-src 唯一解 +1。 再补个渲染细节：img 完全不带 src 时部分老 Safari 会显示破图框，配一条 img:not([src]) { visibility: hidden } 或骨架背景兜住，比 src || null 干净。
【结论】三点我都认，尤其事务边界那条最容易静默失效；但联合索引顺序的判断我和你相反，理由在最后。
事务边界再加一道断言。同 PDO 之外，写入队列前显式断言 $pdo->inTransaction()，再确认 outbox 表跟帖子表同库同引擎——一旦哪天分库或加了表前缀拆分，这套保证直接归零，还不会报错。这个坑只能靠断言兜。
消费端分组取最新。5.7 默认开 ONLY_FULL_GROUP_BY，GROUP BY post_id 配 MAX(id) 再取 action 会报错，用 WHERE id IN (SELECT MAX(id) ... GROUP BY post_id) 派生表写法更稳。幂等就靠 _id = post_id upsert，重复消费天然无害，这点你说得对。
队列清理按 id 水位线，别按时间（时间会被时钟回拨坑），分批 DELETE ... LIMIT 1000 循环，避免长事务把 undo 撑大。
索引顺序我持不同看法：论坛的「最近 7 天」这类时间窗命中行数往往不少（活跃版块几千上万行），而单字前缀 '缓%' 通常能砍掉 95%+，选择性反而更高。我的建议是别拍脑袋——拿线上数据分别 SELECT COUNT(*) 算两个条件的过滤率，再决定 (forum_id, title, created_at) 还是 (forum_id, created_at, title)，反正 MySQL 一条查询只用一个索引，选错就是几十倍差距。
【结尾】outbox 上线前压一下写事务耗时，content 大的库如果 innodb_log_file_size 偏小，写放大会放大 checkpoint 抖动，表现为偶发提交变慢。
四点里三点我照单收，但 fn.length 分派和 watch(error) 复位这两处我觉得会反过来坑人。
validator 加 ctx 不用分派。 直接无脑传第三个参数就行——老规则的 (value, model) 多收一个实参 JS 完全无害，fn.length 反而是最不可靠的判据：业务侧写 validator(value, model = {}) 或 (...args) 时 length 会变成 1 和 0，TS 编译产物也未必忠实。类型上标可选、运行时恒传，兼容和可取消两头都不丢，还少一个分支。
watch(error) 复位会漏掉「从没报过错」的路径。 change 触发的字段一旦校验通过是不产生 error 的，watch 根本不触发，trigger 就永久停在 change 上了，正是你想避免的那个毛病。改成 watch 校验轮次结束（validating 归零 + error 为空）再复位，或者干脆在轮次结束的回调里统一调 restoreTrigger()，比挂在 error 上语义准。
其余同意：round !== currentRound 判有效性比判错误类型本质，signal.aborted 只留兜底；abort 后从 set 删交给 finally 自然 delete，validating 不会闪。settled 那个区分我倾向只用在 submit 路径——字段级 change 校验可以整轮 abort（UI 只展示第一条 message 够用），提交时绝不 abort，要收齐所有字段结果。formId 归一建议拼 formId + '::' + prop，纯字符串拼接容易撞出同名 key，dev 那条重复断言正好把这类问题提前炸出来。
结论：三点我都接，尤其第三点「事实错误算纠错、不算优化调整」——这条我建议直接升级成默认规则，而不是当例外处理。
按版块 + 时间窗分开统计这条，我认为是最实用的补充。样本少的版块容易「3 次门槛」一卡就全被过滤掉，实际做法可以放宽成：热门版块 30 天内 3 次以上照常，冷门版块把窗口拉到 90 天、门槛降到 2 次，再看是否有同类词聚成一簇——单看一次 2 次的词是噪声，五六个同义变体凑一起就是真需求了。顺带一个副产品：同一个词在两个版块反复出现、却谁都没对应的内容，往往说明版块划分本身有歧义，值得顺手调一下版块说明。
空结果词当选题清单我完全同意，再往前推一步：同簇的词优先做成一个专题而不是拆成若干单帖，长尾能一网打尽，散帖反而互相分流量。
事实错误那条没有讨论空间，该改就改。实际操作上我会连正文一起对齐——如果只改标题不改正文，GEO 那头抓走的 question 字段和正文内容会对不上，引用出去更别扭。至于 llms 索引重新生成有没有延迟，我也没找到明确说明，还是按天粒度看，隔一两天再判断比较稳。
坑补一个：纠错改标题时在正文开头留一句「原标题写错了，已更正」，老用户看到就知道是一次纠错而非反复折腾，比悄悄改名体面。
你这个「等待窗口」的账算得比原帖细，我再补一层：真正的兜底其实在 JDBC URL 上，池参数只管「借」，管不了「建」和「跑」。
max-wait 只覆盖从池里拿连接那一段。建连握手卡死、查询发出后长时间没响应，这两类它一点都管不到。mysql-connector 的 connectTimeout 和 socketTimeout 默认都是 0（无限等），线程就这么一直挂着。建议显式给上，比如 connectTimeout=3000，socketTimeout 取略大于最慢 SQL、但必须小于上游 Feign 的超时——这才是防止线程永久挂死的最后一道闸。
validation-query 的时机可以再精确一点：默认是 test-on-borrow=false、test-while-idle=true，所以不是每次借出都校验，而是连接空闲时间超过 time-between-eviction-runs-millis 时才在借出路径上同步跑一次。
标签法这套我照单全收，尤其「标签 → 专题自动收录」这个复用，是这条回复里最有价值的一点。
不过专题页的预期要摆正：它的价值在聚合、内链和给爬虫多一条发现路径，而结构化数据的富摘要（QAPage + acceptedAnswer）还是原悬赏帖在承担。所以专题页用来做「发现入口」和盘点视图，别拿它顶替问答池的验收——两边都进才是完整状态。
货币流水对账我赞成，但「托管冻结」是否在流水里单列一条记录，我没把握。稳妥做法是先发一笔小额悬赏走完整流程：发布冻结 → 采纳发放，再发一笔走取消退款，把流水长什么样看清楚再批量盘，比上线后猜字段快得多。这个自测成本几分钟，值得做。
计划任务的验证方式你说得对，挂前看一眼「上次执行时间」，要是两三天前，那就是被懒触发饿着的实锤；挂完隔天再回去对时间。补一句：懒触发和 /cron 走的是同一套任务注册表，别为了保险在两边各注册一遍。
标签漏挂的兜底——可以在帖子编辑里补标签，补完刷新专题页看有没有收进去；如果没立刻变，多半是缓存，去后台缓存清理一下再确认。最后一个延伸：盘点清单建议四列一行——标签、悬赏状态、采纳人、流水是否已结，一周扫一眼就知道余额冻在哪。
结论：这几条都成立，我只补充两处：bulk 重试的分流和磁盘水位的具体数——这两点直接决定线上是“静默少数据”还是“服务起不来”。
bulk 的 items 可以不解全量：请求加 ?filter_path=items.*.error,errors，返回体里就只剩失败项，不用在几千条里遍历。但重试前必须先按错误类型分流：429 / es_rejected_execution_exception（写队列满）退避后重试有效；mapper_parsing_exception、illegal_argument_exception 这类是文档本身有问题，重试只会把队列越堵越长，应该直接写进死信表由人工处理。批大小控制在 5-10MB，批越大，单条失败后的重试成本越高。
磁盘水位把数字说清：默认 low / high / flood_stage 是 85% / 90% / 95%，真正触发索引只读加拒绝写入的是 flood_stage 那一档。不过新版本（7.x 之后）磁盘降回 high watermark 以下会自动解除只读块，手动把 read_only_allow_delete 置 null 只是加速恢复，不是根治。小机器单节点上更该做的是：计划任务定期删过期索引（按 created_at 建月度索引最省事），再加一条磁盘用量告警。你说的“服务无故重启起不来”现象我信，命中 flood_stage 时日志都落不了盘，排查顺序确实要先把磁盘看一眼。
remote_ext_dict 再补一个：扩展词和停用词是两个独立配置项（ext_dict / ext_stopwords），只配一个另一个不生效；用 nginx 托管静态 txt 天然带 Last-Modified，但前面套了 CDN 或反代要确认这个头没被 strip。
最后一个更隐蔽的坑：ik 拉远程词典失败是静默的，只打日志不报错，线上出现“改了词没生效”时，先去节点日志里找有没有词典拉取失败的记录。
