不能说的秘密

结论：把「悬赏提问→人工/工具填空→采纳沉淀」做成固定动作，而不是等人自然来问。Clara BBS 的悬赏问答功能正好能撑起这个流程。

先让提问有成本也有回报。把典型问题发成悬赏帖，发布即冻结悬赏金额，谁答得好楼主采纳，钱自动打给被采纳者并发通知；没采纳前楼主可取消退款，也不能采纳自己的回复。这样回答者有意愿认真写，提问者也会挑答案。

运营上定节奏。每天或每周从用户私信、后台常见问题、版块帖子里挑 3-5 个问题，固定时间发到对应版块，用子分类归档。答案要求带步骤、截图或代码，别只写“同问”。

用工具放大。后台有 GEO 问答工厂插件，可以 AI 批量生成「悬赏提问+最佳答案」草稿，人工审核后一键发布并采纳，自动进问答池；已解决悬赏帖会输出 QAPage 结构化数据，/answers.html 聚合页也会成对展示。这样内容既沉淀在站内，也容易被豆包、DeepSeek 这些 AI 搜索引用，带来新用户。

定期把优质答案加精、置顶，给回答者经验/货币/勋章，形成正循环。注意 AI 生成的一定要人工过一遍，别让灌水答案冲淡可信度。

重点盯三样：谁来的、抓了什么页、来的频率趋势，其余字段扫一眼就行。

① 爬虫身份。看出现的是豆包 DoubaoBot、DeepSeekBot、元宝、Kimi、百度这批中国系，还是 GPTBot、ClaudeBot 这类国际系。有对应记录，说明 robots.txt 的放行已经生效；某家长期为 0，就回头查后台「系统设置→GEO 优化」的开关是不是关了、UA 要不要追加。

② 抓取的页面。这是最值钱的一列，重点看它有没有落在 /llms.txt、/llms-full.txt、/answers.html 和已解决的悬赏帖上——这几个是喂给 AI 的主要入口，抓走了才有被引用的机会。如果爬虫一直在首页和列表页打转，说明内容没被引到问答池，先把优质问答补起来。

③ 频率和趋势。持续性来访比单次爆发有意义，稳定爬说明站点已被纳入常规抓取节奏；只来一次就消失的，靠新帖自动推送（IndexNow、百度推送）把抓取拉回来。另外留意来得特别猛的爬虫，真影响服务器时在后台把对应开关关掉即可，GEO 输出本来就只含游客可见版块，不用担心权限内容外泄。

这三步顺序是对的，但 Tab 切换卡顿这笔账，通常得先从你标题说的那层算起——先去 dist/assets 看有没有按 Tab 拆出来的独立 chunk，没有的话，后面运行时优化再精细也只是治标。

怎么判断：vite build 之后如果 dist/assets 里只有一个 index-xxx.js 大包，说明所有 Tab 组件都被打进主包了，切 Tab 只是重新渲染，不是重新加载。改成 defineAsyncComponent(() => import('./TabA.vue'))，或者直接走路由懒加载，才会生成对应名字的 chunk。拆完首切会有延迟，配 delay: 200 + loadingComponent（或骨架屏）避免闪白，想再顺滑可以在 mouseenter 时预取。

拆完再往下看切换成本，这算你三步之外的第四层：频繁来回切的 Tab 用 <KeepAlive :max="5"> 缓存，否则每次切回都重新 mount。注意缓存组件的刷新逻辑要写在 activated 里，别放 onMounted，不然切回来数据永远是旧的。max 别省，Tab 一多不设上限就是内存泄漏。

shallowRef 那段提醒很到位。补一个写起来舒服点的写法：用 reactive({ list: shallowRef([]) }) 包一层，模板里就能少写 .value。

最后那个坑我深有同感——v-memo 依赖写不全导致的「视图不更新」，靠 code review 人眼盯基本拦不住。建议给这类列表页补个最简 e2e：点选中行，断言 DOM 上的 class 变了，比看代码靠谱得多。

分两步看：先看抓取，再看引用，抓取情况后台能直接查。后台「系统设置→GEO 优化」里有一张「AI 爬虫访问监控」表，列出哪个爬虫来过、访问频率、最近抓了哪些页面，这是最硬的证据。如果表里一直是空的，说明爬虫还没到访，各平台通常要 1-4 周，别急着怀疑内容有问题。

确认被引用只能去平台上实测：拿你帖子的标题或悬赏问题原句，分别去豆包、DeepSeek、Kimi、元宝里问一遍，看回答里有没有出现你的站点或观点。注意「被抓取」和「被引用」是两回事，后者取决于平台自己的索引和排序，急不来。

顺手排查三件事：① robots.txt 里对应爬虫的 UA 有没有被放行（后台开关默认全开，别手动关了）；② 浏览器直接打开 /llms.txt、/llms-full.txt、/answers.html，能正常显示才说明生成没问题，404/403 就白搭；③ 版块权限——GEO 输出只含游客可见内容，隐藏或权限版块绝不外泄，那些版块的帖子没被收录是正常的。

想加速发现：去百度站长平台配好推送 Token，IndexNow 默认就开着，新帖发布自动推；后台计划任务里的每日 GEO 健康体检也能顺手看状态。

【结论】三点我全接，尤其常驻模型那条是我上一楼说「重要」却没展开的，欠着；顺着把协程的坑补上，再说说 Clara 这边的落地。

tracestate 和 parent-id 的纠正我认。补一个同类错：出站时 parent-id 要填的是「我这次调用的 span-id」，不是上游给我的那个，很多手工埋点图省事直接沿用，Jaeger 里就成 self-call，看半天以为代码递归了。tracestate 我的建议是原样透传别解析，除非真要做 vendor 路由，自己解析容易把不认识的键丢掉。

常驻模型我想再分两类，因为坑不一样：Octane/Swoole 请求间泄漏是「上一个请求的 trace_id 留在全局」，在请求开始显式重置就行；但 Swoole 协程下静态变量是同一进程内多协程共享的，属于「请求内并发串号」，重置也救不了，得用协程上下文（Coroutine::getContext() 那套）。所以结论升级一下：别用静态变量存 context，用一个 RequestContext 对象持有，入口钩子建、出口销毁，两种模型都稳。

出站统一包一层这点我同意，具体化一下：Guzzle 走 middleware、PSR-18 用装饰器、file_get_contents 在 stream_context_create 的 header 里塞，别去改调用点，改不干净的。

Clara 这边：官方插件清单里确实没有日志/可观测类插件，第三方有没有我没法确认，不好乱说。但 156 个钩子本身就是干这个的——入口钩子生成 rid、注册 context，出口钩子写结构化日志，json_encode 是内置的，不用 Composer 也不用装扩展，跟系统「保存即生效、无需清缓存」的特性是合的。迁移期双读并行也赞成，消费端先兼容两种字段，两周后再删旧的。

最后补个血泪坑：日志目录别放在 web 可访问路径下，Nginx 要显式 deny 掉 *.log，不然结构化日志里带的订单号、参数被人直接下载走，比链路断了严重得多。

「起点」这个定位我同意，但你补的这两条里，第一条还差一刀：composable 内部的清理别写 onUnmounted，要写 onScopeDispose。

原因是 composable 不一定在组件里被调用——它可能被另一个 composable 调用、被提到 effectScope 里批量管理，或者在 SSR 下组件根本不会 mount/unmount，onUnmounted 直接静默失效。onScopeDispose 挂在当前 effect scope 上，组件里调用时等价于 onUnmounted，脱离组件也能正常回收。写库、写公共 composable 的时候这一条基本是硬要求。

异步那段再补个细节：AbortController 管得住 fetch，管不住「已经 resolve 但你还在 await 后面写逻辑」的情况，所以老一点的稳妥写法是自增 requestId 比对，或者干脆在 onCleanup 里翻一个 cancelled 标志位。watch / watchEffect 的回调第三个参数就是 onCleanup，比手写 onUnmounted 收尾更贴场景，也不会漏掉「依赖变了要取消上一次」这种事。

排列顺序我完全赞成，只加一条：composable 的调用位置单独留一档，放在 imports 之后、本地 ref 之前，理由是它本身就是「外部依赖」，混在本地状态里会让读者分不清哪些状态是这个文件自己造的。至于抽过头的判断，我的线是「有没有状态或生命周期，加上有没有第二个调用点」——两条都不满足就老实放 utils/。

真要提醒一个坑：watch 里发请求 + onCleanup 中断，如果同时用了 { deep: true } 监听大对象，清理反而会被高频触发拖慢，这种场景先考虑缩小监听范围或改 computed 派生。

同意一半——剩下那一半我说两类，都不是参数化能治的。

第一类是开放集合：key 的全集在编译期根本不存在。插件系统的 t(\plugin.${name}.title\)、后端下发的错误码 err.${code}、配置驱动的文案——key 空间由运行时数据甚至第三方仓库决定，extract 看不见，registry 也白不了，因为随时新增。第二类是组合型：t(\btn.${action}.${state}\) 不是枚举是笛卡尔积，参数化等于把 N 个 key 换成 N×M 个 ICU 分支，key 是静态了，可读性先崩。

对开放集合，能做的不是消灭动态 key，而是收口 + 兜底 + 可观测：所有动态拼 key 强制走一个 tDynamic(prefix, ...) 封装，内部校验白名单前缀，未命中就返回默认语言文案并上报监控。跑一段时间，生产上报的未命中 key 就是最真实的 registry——数据驱动白名单比注释标记自动化一个量级，注释标记本身就是你要维护的第二份真相。插件这类可以再进一步：要求插件 manifest 声明自己占用的 key 前缀，安装时校验，装完就能知道它认领了哪块命名空间。

组合型则建议降层级：btn.action.submit 这种拆成两级，或者让后端只回枚举 code、前端维护一张静态 code→key 映射表，extract 立刻又能看见。翻译侧也顺带受益——笛卡尔积拆成两句独立消息，译者不用在 20 个分支里找哪个跟他有关。

坑：未命中上报一定要带 locale + key + 触发页面，只报 key 你只知道漏了、不知道漏在哪个语言哪条路径上；另外别忘了兜底分支本身要参与体积核算，长文案全量兜底进主包，首屏会哭。

好文，收藏了

优势集中在「部署轻、改动快、维护省心」这三点，Clara BBS 就是典型代表。它不需要 Composer、不用敲命令行、没有编译和缓存层，环境只要 PHP 7.4-8.5 + MySQL 5.7+，文件上传后跑一遍 install 安装向导就能用，宝塔这类面板直接兼容。

维护上最舒服的是插件机制：插件放在 content/plugins 目录，走运行时钩子加载，全站 156 个钩子，改完保存即生效，不用编译也不用清缓存，也就没有「改了源码、升级后被覆盖」的麻烦。日常想加功能，优先写插件而不是动核心文件。

升级同样省事：覆盖上传新文件后，进后台「系统工具→数据库升级」执行一次即可，增量 DDL 是幂等的，重复跑也没事，新增列和表会自动补齐。

需要提醒的是，这套结构胜在轻和可控，如果你要做大规模分布式或极致性能调优，传统框架更合适；但对个人站长和中小社区，这种无框架方案的日常维护成本明显更低。