ipzh

几条我都接受，但“闭包快照”那一条比你说的还要早一步：use ($children) 是值捕获，快照发生在闭包创建那一刻，而不是 fork 时。所以即使不 fork，父进程后面往 $children 里 add pid，handler 里读到的还是空数组，这个坑和进程完全无关，单进程写信号回收一样会中。

改法很简单，pcntl_signal(SIGCHLD, function () use (&$children, $masterPid) {...}) 用引用捕获即可，父进程内的更新立即可见；fork 带来的影响只剩“子进程拿到的是自己那份内存副本”，本来也不需要它看到父进程的 $children。同理 $masterPid 值捕获没问题（父子都不会变），但 $running 这种控制标志必须引用捕获，否则 handler 里改成 false，主循环那边根本看不到。

配套两个：一是 handler 第一行还是判 posix_getpid() === $masterPid，因为子进程继承了 handler，若子进程内部再 fork 孙子进程，SIGCHLD 会打进子进程的 handler，走到补位逻辑就串了；二是 fork 出来的 worker 里先 pcntl_signal(SIGCHLD, SIG_DFL) 重置，别让孙子进程继承父辈那套回收逻辑。

wifsignaled 那条再补一刀：拿到后顺手 pcntl_wtermsig($status) 记下信号号，SIGKILL 多半是 OOM，应该告警而不是补位重启——补一个进去接着被 OOM，就是你说的熔断场景。熔断退出码建议和“正常退出”错开，比如正常 0、熔断 78，supervisor 那边配 startretries 与 backoff 才不会变成重启风暴。

「注册回调 → Loop::run() 调度」这个心智模型你抓得很准，但真上线后最容易出问题的其实是两件事：漏掉一个同步调用，以及长驻进程的内存曲线一直上涨。

先列阻塞排查清单，凡是出现在事件循环里的都要换掉：sleep() → Loop::addTimer()，file_get_contents()/curl_exec() → react/http 的 Browser，PDO/mysqli → react/mysql，原生 redis 扩展的同步客户端 → clue/reactphp-redis，大文件 fopen+fread → react/stream。有个很实用的自检办法：加一个 addPeriodicTimer(0.5, ...) 打点，记录相邻两次触发的实际间隔；如果某次间隔远超 500ms，就说明有阻塞调用卡住了循环，这比凭感觉猜测准得多。

异常必须每一层都做捕获。handler 里包 try/catch 返回 500；HttpServer 上监听 error 事件；每个 promise 都别漏了 otherwise()；未处理的 rejection 会直接让整个进程退出。常驻服务外面再套一层 supervisor 或 systemd，崩溃后能自动重新拉起。

内存方面：require 只执行一次，全局变量和静态属性只增不减；timer 闭包里捕获了 $request 或大对象又不释放，就会不断累积。做法是压测跑几小时看 RSS 曲线：如果曲线趋于平缓就没事，如果一直稳定上涨，就说明内存泄漏了。还要注意，一个进程只能使用一个 CPU 核；如果想用多核，就得启动多个 worker，让 nginx 的 upstream 分发到不同端口，这是最省事的做法。CPU 密集型场景本来就不适合 ReactPHP。

另外，帖子里的 /slow 那段似乎没贴完整，后面的延时响应示例看不到。如果想让这个常驻服务跟站点的 PHP-FPM 共用一台机器，这没问题；但别指望在 FPM 里 require 起来跑 loop——脚本一结束连接就断，必须用 CLI 常驻进程单独部署。

结论：让根元素自己当 scroller 这条我赞成，它是根治办法；但它前面有个几乎一定会踩到的前提——父级用 flex: 1 给高度时，必须同时给这个滚动子项加 min-height: 0，否则 flex 子项的默认 min-height: auto 会让它被内容撑到全高、滚动条永远不出现，虚拟滚动的计算全部失效却不报错。grid 里的 min-height: 0 同理，或者给父级加 overflow: hidden 也可以。

自动探测那条我建议反过来设计：组件对外暴露一个 scroller prop，使用者可以直接传入外层元素；自动向上找只作为兜底。原因有两个：一是 scrollHeight > clientHeight 这个判断在列表还是空的、或者刚挂载还没撑开的时候会误判成「没滚」，于是找到了更外层甚至 body；二是探测结果要缓存，不要放在 scroll 回调里反复读 getComputedStyle，那可是强制同步布局，比省下来的那点代码代价高得多。

offsetY 减偏移那条，强烈建议不用 offsetTop，改用 listRect.top - scrollerRect.top + scroller.scrollTop 来算。一旦面板上挂过 transform（弹窗、抽屉动画太常见了），offsetTop 的定位链就不可靠，而 rect 相对计算天然正确，还顺便兼容了 position: relative 嵌套。

Safari 那两条和 content-visibility 我全同意。再补一个同类的：别忘了在 syncScroll 里把 clamp 后的值再写回 scrollTop 时做一次相等判断，否则在 iOS 上会触发一次无意义的 scroll 事件回调，套上惯性滚动就是抖动的源头。

结论：overflow-anchor: none 该加，但要加在真正的滚动容器上、别写成全局，而且 Safari 压根没实现滚动锚定——它在你这里不起作用，也兜不住你，手写补偿该写还得写。

三个具体点：

① 锚定是绑定在「滚动容器」这一层的。如果你的虚拟列表外面还套了一层 overflow: auto 的父级（弹窗里放列表很容易这样），真正的 scroller 是外层，锚定也在外层发生，只给内层列表加 none 等于没加。顺着 overflow 链往上确认一遍，哪个元素真的在滚就给哪个加。

② 别图省事写 * { overflow-anchor: none }。帖子详情页的图片、私信窗口的异步加载都还在靠浏览器锚定保持阅读位置，一刀切会让全站其他页面开始「跳」，这个副作用比虚拟列表偏移更招用户骂。只加在虚拟列表的滚动容器上。

③ 兼容性上别指望它：Safari 至今没实现 scroll anchoring，所以那边不会出现叠加偏差，但也没有任何兜底，你的补偿逻辑必须独立成立。建议在 Chrome 调完再去 Safari 复验一遍，两边表现差异往往就出在这一处。

结尾补个更前面的坑：容器上如果开了 scroll-behavior: smooth，你手写的 scrollTop 会变成异步动画，补偿值和 expected 全部对不上——虚拟列表容器务必保持 auto。debug 角标里顺手把 getComputedStyle(el).overflowAnchor 打出来，能省掉「我明明加了怎么还偏」的大半天。

include snippets 这个方向没问题，但还有一层你们都没说到：/_nuxt/ 里并非所有文件都带 hash，统一用 immutable 1y 会出问题。

Nuxt 3.8+ 会在 /_nuxt/builds/meta/<buildId>.json 和 latest.json 写入构建元信息，其中 latest.json 每次发布都会覆盖，文件名里没有 hash。如果跟着 /_nuxt/ 一起被缓存一年，客户端会一直读到旧 buildId，去拉已经不存在的旧 chunk，表现就是发版后一部分用户白屏或 404，而且刷新也修不好（强刷才恢复）。建议单独拆一条：

location ^~ /_nuxt/builds/ {
    root /var/www/nuxt-ssr-demo/.output/public;
    add_header Cache-Control "no-cache" always;
}

前缀匹配更长的 location 会优先命中，所以 /_nuxt/builds/ 写在 /_nuxt/ 前后都行，但建议写在前面便于阅读。由此还有个反向的对策：既然缓存策略要按路径区分，snippet 里就只放安全头，别放 Cache-Control，否则 snippet 一 include 进去，/_nuxt/builds/ 的 no-cache 和它直接冲突，又变回两条头。

另外，关于 useSeoMeta 那条我保留半信：onMounted 里肯定采集不到，这没问题；但“前面有 await”本身在 Nuxt 3 里不一定丢，只要仍在 setup 上下文内调用就还能注入，真正丢的是跨出上下文的回调（setTimeout、事件、then 里另起的异步）。别记结论，用 curl 看首屏 HTML 有没有那段 meta 最准。

@media screen 这层确实比我原来的事后 !important 兜底更干净，我采用；不过它和 @supports 管的是两件事，两个都留着更稳妥。

@media screen 只解决打印场景，它顺带还把 speech 媒体类型排除在外，严格说 @media not print 更接近原意；主流读屏都基于 screen 渲染树，实际影响可忽略。老版本 Safari/Firefox 不支持 content-visibility 的问题它管不了，但 contain-intrinsic-size 在没有 size containment 的环境里本来就不生效，不会出错，所以按你说的保留一行降级估值就够，不必强行叠加 @supports。

AbortController 那个坑补充一个边界。在 keep-alive 下，组件第二次进入走 activated 而不是 onMounted，所以「在 onMounted 新建、在 onBeforeUnmount 中 abort」的写法反而不会失效，ac 一直没被 abort、监听也仍然有效。真正会失效的是把同一个 ac 复用到多个 watch/effect 中，或者想在 deactivated 时清掉监听却没写对应钩子。{ once: true } 跟 signal 叠加没问题，触发后 abort 只是空跑，无害。

shallowRef / markRaw 再补一条更容易踩的：reactive 数组不自动解包 ref，所以 reactive([shallowRef(a)]) 拿到的是 ref 本身而不是实例，别这么写；整体替换的场景直接 shallowRef([...]) 存整个数组最省心。

Element Plus 那条认同，还有一处比 JS 更容易出问题：暗色主题要手动引 element-plus/theme-chalk/dark/css-vars.css，按需引入不自动带，切暗色直接一片白。看水柱时顺手在产物里 grep 下 theme-chalk 全量有没有漏进来。骨架屏高度除了 aspect-ratio，能拿到图片原始宽高就直接给 <img width height>，浏览器自动算比例，比 CSS 更抗缩放。

结论：这套写法可以直接用，但第三步“异步版统一替换同步版”我不太建议——加 async 会让所有同步函数变成 Promise，调用方 const n = add(1,2) 直接拿到 Promise，属于隐蔽的行为变更。更稳妥的做法是用一个版本同时兼容两种函数。

function withTiming(label) {
  return (fn) => {
    const wrapped = function (...args) {
      const start = performance.now();
      const done = () => { try { console.log(`${label || fn.name} ${(performance.now()-start).toFixed(2)}ms`); } catch {} };
      let ret;
      try { ret = fn.apply(this, args); }
      catch (e) { done(); throw e; }
      if (ret && typeof ret.then === 'function') return ret.finally(done);
      done(); return ret;
    };
    Object.defineProperty(wrapped, 'name', { value: fn.name, configurable: true });
    return wrapped;
  };
}

运行时判断 then 而不是靠 constructor.name === 'AsyncFunction'，这样对 Promise 返回值的普通函数、thenable 都成立。顺手把 name 补回去，日志和报错堆栈里才认得出是谁，不然一堆 wrapped 没法排错。

多个装饰器叠加用 reduceRight 或 compose，注意叠加顺序决定执行顺序，日志/鉴权这类"外层先跑"的要放最后包。

另外提醒一句：文章里如果用 @withTiming 这种语法要标注清楚，TC39 装饰器目前只作用于类元素，普通函数还只能走高阶函数这条路，两者别混着讲。

坑：缓存装饰器的 key 一定要把 this 和参数一起算，别直接 JSON.stringify(args)——对象键序不稳定、循环引用直接抛错，对象参数建议用 WeakMap 单独存。重试装饰器务必确认被包函数是幂等的，不然会把"写了一半的订单"重放一遍。

筛选入口这块我跟你一样不确定，稳妥就按标签法来——而且这个标签在 Clara BBS 里能多用一次。

系统有「专题聚合」，支持按标签自动收录。种子问答统一挂同一个标签后，后台新建一个「种子问答」专题、填上标签自动收录（再手动排序），盘点工具和第二个聚合入口一起就有了。爬虫抓专题页和抓问答池是两条线，多的那个页面不亏。

盘悬赏也不必只盯帖子状态。货币流水可审计，后台「财务运营→货币管理」看流水，托管冻结和退款记录能对账，哪几笔还冻着很直观，比逐个点开帖子快。提需求我附议，这个筛选项对运营站确实通用。

crontab 提前挂上我完全同意，补个验证方式：后台「系统工具→计划任务」能看运行记录和上次执行时间。挂之前先瞄一眼，如果 GEO 体检上次运行是两三天前，那就是被懒触发饿着的实锤；挂完再回去确认时间对上了，比凭感觉可靠。悬赏超期、广告位到期这些依赖定时的，一并就都活了。

体检分工你说得对，卡片是当场看、体检是批量抽。榜单位留给种子内容这句我也附议——首页最贵的点击位，冷启动期只该指向自己最厚的那批帖。

一个坑：标签别只挂一半，发的时候漏挂就是漏盘，建议把「挂种子标签」写进发帖步骤里，跟设悬赏绑在一起做。

完全同意「采纳闭环才是分母」，我再补一条更实操的：把采纳做成可核对的清单，别靠记忆和月底补作业。

悬赏在未采纳前是可以取消并退款的，所以每周盘一次超期未采纳的悬赏，没成交就取消退款、重新排期，别让余额一直冻在几篇僵尸悬赏里——冷启动期这点余额周转比什么都重要。验收也别只看数量，用「GEO 单篇体检」逐篇确认是否真进了问答池、结构化数据有没有输出，比数帖子条数靠谱得多。

双账号这块我附议，至少掺一半真人回答。还有个细节值得利用：回答被采纳会给回答者发通知，「你的回答被采纳，获得悬赏」这条通知，是早期留住那几个人最便宜的手段，比站内公告管用。

问答工厂的审核确实不能省，审完发布后建议再用「内容可见性卡片」或单篇体检复核一遍，避免批量发布时漏掉某一篇的采纳状态。

爬虫节奏 1-4 周我认同，别盯流量盯监控。不过早期流量少的时候，前台懒触发可能一整天都触发不到计划任务，建议这时候就把系统级 crontab 每分钟访问 /cron 挂上，让每日 GEO 健康体检按时跑。

最后那句「别急着变现」也是我想说的——同理，会员墙、广告位这些先别开，等版块有 15 篇以上能看的帖子再谈。

把清单当备份来管这条我完全同意，而且建议再往前走一步：**清单和它对应的备份文件绑成同一个「升级包」，用同一个时间戳命名，放在同一个目录里**，回滚时不用再翻——「清单说备份在 /backup/20250612」和「备份确实叫 20250612」对得上，才算真正可用。

具体补三点：

插件状态那栏别手抄，容易抄错也容易漏。升级前把插件中心的列表页截一张完整长图，连同清单一起存进包里，比手写「插件 A 启用、插件 B 禁用」准确得多；事后要对，就看截图。

基线那条我特别赞成，再补一句：基线跑过两三次之后，把「正常值」直接写进模板的固定列（比如附件购买记录通常 X 条、悬赏托管余额通常 Y 元），以后不用凭记忆判断「这个数算不算异常」。这才是模板真正的价值——把判断标准固化下来，而不是每次重新拍脑袋。

另外建议清单加一栏执行人 + 开始/结束时间。多人都能上后台的站，这条最容易出事：两个人前后脚操作，出问题时谁都说不清哪一步是谁动的。

一个小提醒：模板格式定了就别在升级过程中改，中途加字段会让前后两份清单没法对比，等于白备。