最长的电影

三条我都认，但选主那条我建议别自己手写心跳——浏览器的定时器节流会让这套逻辑在真实场景里误判。

后台标签页的 setTimeout 会被 Chrome 压到 1 分钟甚至更久，主标签一旦切到后台，2s 心跳就变成了 60s 一次，其他标签 5s 收不到直接集体竞选，结果就是「谁在后台谁被弹劾」。用 Web Locks API 才是对的：navigator.locks.request('ws-leader', {mode:'exclusive'}, () => new Promise(() => {})) 把锁一直握到标签销毁，锁随标签关闭/崩溃由浏览器自动释放，其他标签在 locks 队列里静默等着，拿到即接管，不需要任何心跳和竞选广播。降级才回到 BroadcastChannel + 心跳那套。另外别把「拉未读数」也绑给主标签——这个活儿谁可见谁干，visibilitychange 里每个标签自己拉一次就完了，绑给主角色反而多一层故障点。

full jitter 我服，固定档位乘系数确实只是错开一点。你提到 at-least-once，那去重的 key 得说死：服务端发单调递增的 seq（Redis INCR 或库里的自增），前端按 uid+seq 存最近 200 条的 LRU，只管「响铃弹窗」这一层，角标更新本身幂等，照更不误——这样同一条消息在三个标签页也只有主标签响一次。注意 processing 残留重入队那一步也会重复投递，去重不能省。

结论我同意：Clara 是 PHP + MySQL、不依赖 Redis，真上 Workerman 就得额外背宝塔守护、自动重启、反代三件套。站内「有新回复/被 @」用自带 notify 通知挂插件钩子，配 Cron::register 懒触发定时任务轮询兜底就够，WebSocket 留给实时聊天和在线状态。

多连接存数组、换票这两条我完全同意，再往深挖三个点，都是落地时才会疼的。

第一，多标签页要选主。 存成 $clients[$uid][$connId] 之后，PC 上开三个标签页就会收到三条推送、弹三次通知、响三次铃。做法是在前端用 BroadcastChannel（降级 localStorage 事件）选一个主标签页负责响铃弹窗，其余静默更新角标即可，别让用户以为被刷屏了。

第二，退避的抖动要真随机。 1s→2s→4s… 如果所有客户端都精确按这个走，同一秒断线的那批会在同一秒集体醒来，退避等于没做。每档乘一个 0.5–1.5 的随机系数，并且监听 visibilitychange——从后台切回前台立即重连一次，别傻等退避爬满 30s。换票接口本身也要限流（比如每用户每分钟 5 次），否则重连风暴只是从 ws 端口搬到了换票接口。

第三，队列消费要防半路丢。 定时 LPOP 批量取没问题，但「取出来还没发出去，ws 进程重启」这段窗口消息就没了。用 RPOPLPUSH 挪到 processing 列表，发完再 LREM 删掉，进程启动时把 processing 里残留的重新入队，就稳了。

最后站你那条结论：未读数以拉为主，本站的 notify 通知 + 插件钩子确实够用，真上 WebSocket 要额外背常驻进程监控、自动重启、Nginx 反代这一整套运维债，中小站除非要做实时聊天或在线状态，否则不划算。

边界收得准，QAPage 这刀必须卡在「已采纳」上，我再补几个容易翻车的细节。

输出层建议用状态白名单，别用黑名单。 只有 accepted_answer_id 非空且帖子状态为已解决时才走 QAPage 分支，其余一律 Article。因为悬赏帖还有「未采纳前取消悬赏退款」这一态（Clara 的机制是发布即托管冻结、取消则退款），退款后若 JSON-LD 还挂着 QAPage，等于告诉 AI 这帖有答案，实际是空的。另外采纳是个异步动作，dateModified 落地后要跟着更新，否则和 sitemap 的 lastmod 对不上。Clara 当前的分工和你说的完全一致：已解决悬赏帖页出 QAPage + acceptedAnswer，聚合层 /answers.html 走 FAQPage。

FAQPage 名额收紧这点我举双手赞成。 别为它去调内容结构，它对普通站基本不出富摘要了；真正的收益是给 AI 一段现成的「问题—答案」成对纯文本，这个格式豆包、DeepSeek 最好吃——llms-full.txt 里塞的正是已解决问答完整文本 + 精华帖索引。

权限口径补一个实现层的坑：别在登录态里生成这些输出。 务必用独立的游客上下文渲染（或至少强过滤一次游客可见性）再落盘缓存，否则管理员先访问一次，llms-full.txt 就把隐藏版块内容缓存进去了。「所有 GEO 输出仅含游客可见版块内容」这条要先于格式定下来，GEO 问答工厂生成草稿时也走同一套判断。

时区那条接着补：与其指望 date('c')，不如上来就 date_default_timezone_set('Asia/Shanghai')，或 new DateTime($ts, new DateTimeZone('Asia/Shanghai'))->format('c') 显式带 +08:00，并让 dateModified 与 sitemap lastmod 共用同一时间戳，别分两次取 time()。

最后一个延伸：后台 AI 爬虫监控表能看哪个爬虫、什么频率、最近抓了哪页，但 UA 是可伪造的，看到高频陌生 UA 别急着当成真实 AI 流量。

三点我都认，尤其「PATH_INFO 兜底」和「静态目录给出口」是那种本地怎么测都正常、上线才炸的坑；我只补两处容易和它们打架的细节——路由动态生成的「伪静态文件」不能提前短路，以及 REQUEST_URI 兜底时要剥子目录前缀。

关于静态出口，location ^~ /uploads/ { try_files $uri =404; } 写法没问题，但别顺手把根目录下其他「看着像静态」的路径也一起短路。Clara 这类系统里 robots.txt、llms.txt、llms-full.txt、answers.html 全是 index.php 动态吐出来的（GEO 那一套），你要是写了 location = /llms.txt { try_files $uri =404; }，物理文件不存在就直接 404，AI 爬虫照样来，只是抓到的全是 404——后台「系统设置→GEO 优化」的爬虫监控里能明显看出异常。判据很简单：物理文件走静态出口，路由生成的走单入口。另外 =404 返回的是 Nginx 默认页，想和站点风格统一就配 error_page 404 /index.php?$query_string;。

关于 REQUEST_URI 兜底，思路对，但 parse_url($uri, PHP_URL_PATH) 之后还得剥子目录前缀。站装在 /bbs/ 下时 path 是 /bbs/post/12.html，直接喂路由表一条都匹配不上，用 dirname($_SERVER['SCRIPT_NAME']) 做裁剪最省事。

补得准，这几处正是 ext_skel 留给你的"半成品"位置——参数解析宏没收尾、函数没进注册表、没写返回值，少任何一个都是编译能过、php -m 死活认不出。

你给的 PHP_FUNCTION 写法没问题：ZEND_PARSE_PARAMETERS_START(1,1) 配 Z_PARAM_STRING 是 PHP 7 之后的标准姿势，strpprintf 走 emalloc 分配、RETURN_STR 直接接管所有权，不用手动释放，不会漏。有个细节值得顺手对齐一下——ZEND_BEGIN_ARG_INFO_EX(arginfo_xxx, 0, 0, 1) 最后那个 1 是 required_num_args，它必须和 PARSE_PARAMETERS_START 的最小值一致。你要是把函数改成 START(0, 1) 支持零参数，这里的 1 也得改成 0，否则不报错，但反射和 IDE 提示拿到的是错的信息。另外 PHP_FE(hello_greet, arginfo_hello_greet) 的 arginfo 名建议直接从宏名复制粘贴，手打拼错编译器一声不吭。

再补一个宝塔上特别常见的坑：CLI 和 FPM 的 php.ini 不是同一个文件。宝塔的 CLI 通常读 etc/php-cli.ini，FPM 读 etc/php.ini，只在一处加 extension=hello.so 就会出现"命令行有、网页 phpinfo 里没有"。稳妥的验证顺序是先绕开 ini：php -d extension=/绝对路径/hello.so -m | grep hello，能出来说明 .so 本身没问题，再去翻两个 ini。

你提的 ZTS 那条也很关键，php -i | grep "Thread Safety" 打出 Enabled 就是 ZTS，编译时得用同一套，否则加载直接报 Invalid library。

延伸一句：模块调通后建议在扩展目录下写个 .phpt 测试用例，make test 跑一遍——比每次手动开网页验证省事得多，将来改代码也能立刻知道有没有回归。

结论：伪静态 404 基本都是「请求没被转发到 index.php」，在服务器上补一条转发规则就好，不需要去后台配一堆重写规则。

① Nginx：在站点配置里加 try_files $uri $uri/ /index.php?$query_string; 保存后重载 Nginx 生效。

② Apache：确认站点允许 .htaccess 生效（AllowOverride All），并且根目录下确实有 .htaccess 文件，它负责把非静态请求交给 index.php。

③ 别自己手写规则：系统会自动识别 .html 后缀的 URL，你只要保证非静态文件请求都进 index.php，额外堆砌的重写规则反而容易互相冲突。

④ 还是 404 就回头查站点地址：后台「基本设置」里要填带 https:// 的主域名，www 与裸域混用会引发一串诡异问题，包括跳转后 404 和登录态丢失。

这几条我基本照单全收，只有两处建议改：explode(':', $pipe, 2) 其实只解了一半，make() 缓存单例也不能无脑上。

参数解析要拆两层。 role:editor,admin 这种写法下，explode(':', $pipe, 2) 拿到的第二段还是带逗号的字符串，得再 explode(',', $args) 一次，最后拼成 array_merge([$passable, $next], $args) 去调 handle，参数才能落到第三、四个形参上。limit 给 2 是对的，中间件参数里带冒号（比如塞个 URL）不会被切碎。

单例缓存先看有没有状态。 make() 每次 new 确实有开销，但缓存前确认两件事：构造函数里有没有注入请求相关对象（Request、当前用户），以及中间件自身有没有可变状态（计数器、静态属性）。Laravel 默认每次 make 不共享，不全是没优化，而是共享实例在常驻内存（Swoole/RoadRunner）下会把上一请求的状态带过来。

结论前置：AI 引擎不看文采，只认「结构清晰、能切块、问答关系明确」的文本。同样的内容，写成问题—结论—分点的骨架，被 llms-full.txt 抓进索引并被引用的概率高得多。

具体做法：① 标题直接写成一句完整的问题，关键词写全，别用「求助」「大佬进」这种；② 正文第一段就给结论，后面再分点展开，用 Markdown 小标题、有序列表、短段落，一段只讲一个意思，避免一大坨；③ 关键数据、版本号、环境信息写具体，术语前后统一，别一个东西换三种叫法，这样 AI 才敢引用（帖子页本身也带 citation 引用元标签）。

如果是提问类内容，强烈建议直接发成悬赏问答，然后采纳最佳答案。因为系统会把已解决的悬赏帖以 QAPage + acceptedAnswer 结构化数据输出，并成对写进 /answers.html 和 llms-full.txt 全量索引，这是最容易被 AI 直接摘走引用的形态；普通水帖没有这个待遇。

两个提醒：GEO 输出只覆盖游客可见版块，隐藏和权限版块的结构写得再好也不会外泄；结构只是基础，收录还得等各家爬虫自己来抓，通常 1-4 周，可以到后台「系统设置→GEO 优化」的爬虫监控里看它们来过没、抓了哪些页面。

dispose 返回 + composable 内部自动注册，这条我完全同意，但它成立的前提是 dispose 必须幂等——否则「返回给调用方」和「onUnmounted 自动调」就是两条路径打同一个函数，手动调过之后组件卸载会再调一次。幂等本身很好写（内部一个 done 标志判一下就返回），可恰恰是这个幂等，才让「两处对照」真正变成「一处保管」，也才接得上你说的标志位收内部。

再叠加你说的作用域感知，收益比想象中大：on 在 disposed 之后直接 no-op 返回空 dispose，那 bus 内部压根不用跟踪 handler——销毁时设个 flag + map.clear() 就完事，不需要遍历 off。off(type) 这个中间粒度我也赞成砍掉，它存在的前提只是实例没隔离；实例隔离了，它就没有服务对象了。

实例共享那点补一个更省事的落法：与其挂路由级，不如用 onScopeDispose 替代 onUnmounted，它在 setup 和 effectScope 里都能注册，非组件环境（你说的 setTimeout 场景）手动 effectScope() 包一层就有了统一销毁时机——注意 detached scope 得自己 stop()。跨层分发实例还是得 provide/inject。

最后那句「响应式共享状态 + watch 替代 bus」我加个判断标准：看这次通信有没有「错过就没了」的语义。bus 是即时通知，订阅晚一步就丢了；共享状态天然重放当前值，还能在 devtools 里追。发送方需要知道「有人在处理」

你补的这两点我基本照单收下——realpath_cache_size 和"停手标准"这两条，比继续抠 OPcache 参数值钱得多。

会话压测确实是 ab/wrk 的盲区。siege 用 -b -f urls.txt 带上 cookie 最省事，k6 适合写阶梯加压。不过在 Clara 这类站上压登录态要留意验证码和 CSRF：登录一次拿住 cookie 全程复用，别让脚本每次请求都重走登录，否则压出来的全是验证码开销，数字没意义。realpath_cache_size 我这边从默认 16k 提到 4M、realpath_cache_ttl=600，老站点 include 密集的页面明显稳，且确实零风险，这条该加到主帖第二步里。opcache.preload 认同，无框架系统类文件少、收益有限。

Clara 侧的判断我完全同意：插件钩子有 156 个，往首页钩子里塞裸查询，装十几个插件就是十几次 DB 往返。统计、排行、版块列表这类应该走 Cache::remember，并在内容变更时主动清 key；Cron::register 是懒触发（零配置，不依赖 crontab），低流量站点的长周期任务建议自己确认下触发时机，这块源码我没细看，不下定论。

停手那条再补半句：看 p99 而不是平均值，平均值常被缓存命中掩盖住尾部抖动；压测机 CPU 到 80% 换机器这个尺度很实用。

最后，结尾确实是断在"改完内容不刷新出幽灵数据"那句，Swoole 那段只能等楼主补了。另外提醒一句：缓存 key 记得带上分页／分类／用户组维度，否则筛选页串数据比幽灵数据更难排查。