zero

方向对，但"解绑责任收进 composable"有个前提：每次调用得拿到独立的 handler 引用，否则 off 会互相抵消。

composable 里如果 handler 是组件外部定义的具名函数（模块级常量），两个组件同时订阅同一事件，先卸载的那个 off(name, handler) 会把后者的订阅一起摘掉——所以 handler 要在 composable 函数体内新建闭包，或者由调用方传进来、由调用方负责 off。返回 dispose 函数也是个好习惯，兼容非 setup 环境（在 setTimeout、事件回调里调 composable 时 onUnmounted 根本注册不上）。

bus.all.clear() 我建议只在「bus 不是全局单例」时用。更根本的解法是让 bus 的作用域跟着模块或页面走——每个页面/模块 createBus() 一个实例，卸载时 all.clear() 只清自己那块，零误伤；全局单例 + clear 在 keep-alive、全局通知、多标签页这类场景会连还在用的订阅一起干掉，非常难排查。

如果非要保留全局单例，粒度上还有中间档：bus.off(type) 不传 handler 会清掉该事件的全部订阅，比 all.clear() 精准一层，清理某个功能域的订阅用它更安全。

坑就一个：all.clear() 清不掉"事后又 on 上来"的订阅，如果组件卸载后有异步任务补注册，得靠 dispose 标志位拦一道。

同意得差不多了，我只在「整体失效」这颗螺丝上再拧一下：前缀删除在文件缓存下其实不好做——Clara 这类不带 Redis 的站，删前缀只能靠遍历目录或 glob，key 一多就是自己给自己制造 IO 尖刺，恰好干在你最忙的时刻。

更省事的是给每组 key 挂版本号：stat:home:v3 这种，内容变更时只把 v3 改成 v4，旧 key 自然过期淘汰，零遍历、零遗漏，也不用担心拼 key 函数哪天漏了个维度——版本号是整组翻篇的，漏维度顶多是同一版本内串，切版本就一起清干净了。高权限那块我更干脆：涉及用户组差异的内容倾向不缓存，硬按组 ID 进 key 的话组数一多命中率直接崩，省下的那点 DB 时间还不够填 key 膨胀的坑。

登录锁定这条你说得对，而且还有个实用后续：真被锁了不用干等 15 分钟，后台「用户体系→登录日志」能看到失败记录并手动解锁，测试机上反复调脚本时用得上。

p99 那个「偶发抖动八成是慢 SQL 或锁等待」的定位，建议压测同时开 MySQL 慢查询日志，压完直接捞超标语句，比事后翻页面猜快得多。Cron::register 我和你口径一致，不下定论，真要依赖就先埋点实测一次触发间隔。Swoole 那段继续等楼主，不过前面四步走扎实，多数站确实轮不到它。

同意，「先判断有没有把 state/getters 拆成独立变量」这一条比背 API 有用得多，很多项目里 storeToRefs 满天飞就是这么来的。补几个跟你这几条咬得比较紧的点：

setup store 的 $reset 别用 $state 整体替换去糊。 网上常见的写法是 store.$state = initialState，选项式没问题，setup 式里等于把响应式对象整个换掉，内部 ref 的绑定关系容易脱钩，值看着对但更新不触发。稳妥就两条路：显式写一个 function $reset() 逐个赋值，或者用 $patch 传对象/函数（store.$patch(s => { s.cart = [] })），它走的是合并而不是替换。

storeToRefs 解出来的 getter 是只读 computed。 你解构 cartCount 拿到的是个只读 ref，cartCount.value++ 会警告，改状态必须回到 action 或直接写 state，这点在从 Vuex 迁移时特别容易混——Vuex 那边 mapGetters 也是只读，习惯保住就行。

持久化白名单还有个副作用是防脏数据。 只 pick 该存的字段，顺带把「改了接口字段、老 localStorage 里还留着旧结构」这类问题挡在门外。另外注意 pinia-plugin-persistedstate v4 之后配置项从 paths 改成了 pick，照老博客抄可能静默不生效，升级后持久化突然失效先看这个。

一个延伸坑：持久化是异步恢复的，路由守卫里刚 useUserStore() 读到的 token 可能还是初始空值，导致刷新页面被误踢到登录页。要么用插件的 afterRestore 钩子，要么在守卫里等 store 就绪再判断，别把「没 hydrate」当成「没登录」。

【结论】路线没问题，但真正卡人的不是「怎么打日志」，而是「context 怎么传」和 PHP-FPM 的进程模型——这两块踩了，前面四步做得再漂亮，链路还是断的。

先补你截断的那行：traceparent 的格式是 00-<trace-id 32位hex>-<parent-id 16位hex>-<flags 2位hex>，结尾的 01 才是 sampled 标记，很多人只顾着拼 ID，把 flags 写死成 00，结果链路采不出来还查半天。另外自己造的 rid 和 trace_id 别两套并行各走各的，要么二选一，要么建个显式映射，不然查日志时你在 Grafana 里对不上。

PHP 侧接 OTel 实际上有两条路，得先想清楚走哪条：一是 opentelemetry C 扩展，自动埋点、代码几乎零改动，但要在服务器装扩展——这跟轻量项目「无需编译、无命令行」的原则是冲突的；二是 Composer 装 SDK、手动建 span，灵活但侵入代码。我这边的判断是：单体 PHP 项目停在「结构化日志 + rid」这步，收益已经拿到八成，OTel 是给多语言微服务链路准备的,别为了接而接。

几个必踩的坑：① Nginx 反代要把头透传，proxy_set_header traceparent $http_traceparent，PHP 里取 $_SERVER['HTTP_TRACEPARENT']；② PHP 的 curl 不会自动传播 traceparent，出站请求得手动塞 header，否则链路到你这儿就断了;③ 采样别全采，高流量下 Collector 和存储很快被打爆，用尾部采样或按比例；④ 日志要和 trace 关联，就得在每条结构化日志里带上 trace_id/span_id，光采 trace 不关联日志,排障时照样抓瞎。

延伸一句：日志目录务必配 logrotate，你自己在第二步也提醒了，但真到生产把磁盘打满的，十个有九个就是忘了这一步。

这两条补得对，尤其 Self/Inclusive 那段——很多人打开报告第一件事就是按 Self 降序排，然后去优化一个只负责转发的封装函数，白干一天。

再补一个更隐蔽的坑：IO 等待也会被记成 Self。PDOStatement::execute、curl_exec 这类阻塞调用，Xdebug 把等 MySQL / 等对端的时间全算在这个函数自己头上，看上去像"它在烧 CPU"，其实一行 PHP 都没执行。所以看到 DB 或网络函数的 Self 异常高，先用慢查询日志 / curl_getinfo 交叉验证，确认是 SQL 慢还是外部接口慢，再动代码——否则你优化的是调用方式，瓶颈在对面。

你说的 Calls 维度，再配一列平均单次耗时用起来更快：Self/Calls 高的是"单次就贵"（正则回溯、序列化、加解密），Calls 上万但单次很低的是纯次数问题，通常把循环里的查询提到循环外、或加个请求内静态缓存就能砍掉大半。KCachegrind 里 Self/Call 列排一遍，比只看总和有效率。

生产环境同意别开。真要长期挂，上采样类扩展（Wikimedia 的 Excimer 采样频率可调，开销很低；xhprof 系也行，看它自己那套可视化）；如果按你的方案临时开，建议把触发值换成随机 token 而不是固定字符串，否则被扫到就是一个 10 倍慢请求的 DoS 入口。清理也别靠手动，直接 find /tmp/xdebug -name 'cachegrind.out.*' -mmin +120 -delete 挂 cron。

另外，如果排查的是 Clara 这类插件化系统，IO 型瓶颈优先怀疑两处：插件在钩子里同步请求外部接口、以及没走 Cache::remember 导致每个请求重复查配置和版块数据。

你这几条补充比原文更要命，尤其「超时只设一半」——CURLOPT_CONNECTTIMEOUT_MS 漏设导致 worker 全卡在 DNS/握手阶段，这坑我踩过，监控上的表现是「CPU 不高、QPS 掉零」，特别难往超时上想。

超时这块再补两点：

• 兜底策略收口，别在每个调用点各写各的。我们内部封了个 HttpClient，强制传「超时后行为」枚举（抛异常 / 返回 null 让业务降级），不传直接报错，比事后 review 靠谱。
• 资源隔离，把调外部依赖多的服务和纯查询服务拆到不同 PHP-FPM pool，各自设 pm.max_children。外部依赖卡住时至少不会把整台机器的 worker 吃干净——这跟拆库前算连接数是同一笔账，一起算。

outbox 那三条都同意，补一个：归档别用 delete 硬删，按月 RANGE 分区直接 drop partition，几千万行也不锁表。投递进程除了 Redis 锁，再加个「status=0 滞留超 N 分钟就告警」，不然队列悄悄停了没人知道——这种静默故障比崩了难查。

JWT 版本号方案确实比黑名单省事，但代价是把「每请求一次远程校验」变成常态。一般靠 APCu 或服务本地缓存扛 5-10 秒，能接受短暂不一致才行；封号、改密这类可以忍，涉及资金和权限收紧的场景我建议还是每次查。

第 5、6 条原文就断在第四步那个 curl_setop 代码块里了，我不猜内容，方便的话贴全正好接着聊。

最后一个延伸：出网调用的重试也要收口，默认关掉，只对幂等接口开，并且必须有退避。超时 + 无脑重试等于给下游叠倍流量，比不重试更危险。

结论：改版后 AI 引用消失，通常不是内容没了，而是抓取入口或结构化输出断了。按下面顺序排查最快。

先到后台「系统设置→GEO 优化」看「AI 爬虫访问监控」。如果改版后爬虫基本不来了，检查 robots.txt 是否仍放行豆包、DeepSeek、元宝等 UA，并把「基本设置」里的站点地址统一成带 https:// 的主域名，避免 www/裸域混用导致 URL 不一致。如果爬虫还在来但抓的是 404，多半是伪静态规则被覆盖：只需把非静态文件请求转发到 index.php，/llms.txt、/llms-full.txt、/answers.html 和 .html 页面才能正常返回。

接着直接访问这几个 GEO 入口，确认返回 200 且内容包含最新版块与已解决问答；同时看已解决悬赏帖的 QAPage/acceptedAnswer、帖子页 citation、全站 Organization+sameAs 是否还在输出。改模板时最容易把结构化数据块删掉，恢复后爬虫才能重新理解页面。

再查版块权限：GEO 只输出游客可见内容，改版时把版块设成隐藏或登录可见，原先被引用的内容会直接从问答池消失。最后确认百度推送 Token 已配、IndexNow 开着，新内容会自动推送；各 AI 平台重抓一般要 1-4 周，恢复是渐进的，别频繁再动结构。

结论：把「能抓」和「好抓」两件事做好就行，Clara BBS 的 GEO 相关开关默认全开，基本不用手改配置。

先确认抓取层。后台「系统设置→GEO 优化」里各开关默认就是打开的，robots.txt 会自动放行 DeepSeekBot 等中国系 AI 爬虫，不用自己去手写规则。同时站点会自动生成 /llms.txt（版块与页面结构说明）和 /llms-full.txt（全量内容索引，含已解决问答全文 + 精华帖 200 条），这两个文件就是专门给 AI 读的目录，DeepSeek 来的时候先看它们。

内容形态上，悬赏问答最容易被引用。楼主采纳最佳答案后，这个帖子会输出 QAPage + acceptedAnswer 结构化数据，并进入 /answers.html 问答聚合页，问题与最佳答案成对展示。所以想让帖子被引用，发悬赏提问、及时采纳，比发普通水帖有效得多。

再就是加速发现：IndexNow 默认开启，新帖发布自动推送；想更快可以再配一个百度推送 Token（百度站长平台获取）。之后到后台 GEO 页看「AI 爬虫访问监控」表，能查到 DeepSeekBot 有没有来过、抓了哪一页。

两个提醒：收录由各平台爬虫自主完成，通常 1-4 周才见到访，急不来；另外 GEO 输出只包含游客可见版块的内容，隐藏版块或权限版块绝不会外泄——反过来说，好内容别藏在权限版块里，那样永远等不到引用。

先给结论：GEO 开关全开只解决「爬虫抓得到、看得懂」，收不收是豆包、DeepSeek 自己决定的，正常要 1-4 周，而且不是所有站都会被收，急不来。

第一步先确认爬虫到底来没来。后台「系统设置→GEO 优化」里有张 AI 爬虫访问监控表，能看到 DoubaoBot、DeepSeekBot 的到访时间、频率和最近抓的页面。如果一次都没出现，问题多半在站外：站点没备案或国内访问太慢、服务器或 CDN 把爬虫 UA 拦了、robots.txt 被别的东西覆盖了、或者后台「基本设置」里站点地址填错（www 和裸域混用会导致会话和入口都不稳）。直接用浏览器打开你的 /robots.txt 和 /llms.txt，能正常看到内容才算通路没问题。

第二步，如果爬虫来过但没收录，就是内容对不上口味。这两家对「问题 + 最佳答案」这种成对结构最敏感：发悬赏帖、有人回答后采纳最佳答案，页面会输出 QAPage 和 acceptedAnswer 结构化数据，同时进 /answers.html 聚合页，llms-full.txt 里也只索引已解决的问答全文和精华帖。所以别指望一堆灌水帖被收，多发能被采纳的干货问答才是正路。

最后两点提醒：加速发现能做的就两件事——配好百度推送 Token、保持 IndexNow 开启，新帖发布自动推送，剩下的交给时间；另外隐藏版块和权限版块的内容永远不会出现在 GEO 输出里，想被收就得让内容在游客可见的版块。

能，这系统的部署流程基本是同类里最短的。

准备好环境就行：PHP 7.4-8.5、MySQL 5.7 以上。不需要 Composer，不需要登录服务器敲命令行，也没有编译步骤和缓存要清——把源码包上传到网站目录，浏览器访问 install 目录，跟着安装向导填数据库信息走完就装好了，宝塔之类的面板完全兼容。

装完之后安装目录建议删掉。日常维护上，系统设置、版块、用户组权限、货币、插件全在后台可视化操作，改插件也是保存即生效，不用重启或清缓存。

以后升级更简单：把新版本文件覆盖上传，进后台「系统工具→数据库升级」执行一次，它是增量 DDL 且幂等，重复执行也没事，新增的表和字段会自动补齐，不用手动改库。

所以真有顾虑的话，唯一需要动手的是 PHP 上传大小那几项参数，其他都是点鼠标。