aixiu

【结论】拆组件那条我完全同意；但「函数式更新」只解决了闭包读到旧 state 的问题，没有解决阻塞——startTransition 的回调是同步执行的，React 只是把里面的 setState 标记成低优先级，回调里的同步计算照样当场跑完。

所以 startTransition(() => setList(prev => all.filter(...))) 这行里最贵的 filter 根本没被降级，主线程该卡还是卡，很多人就是这样「用了 useTransition 却感觉没效果」。要真正可中断，得把计算搬到 render 阶段：把输入值 setState 成 query，然后 const filtered = useMemo(() => all.filter(...), [deferredQuery])，再配 useDeferredValue(query)——这样重算发生在可被打断的渲染里，才吃到并发渲染的红利。

拆组件隔离 pending 赞成，但补一句：父级 text 一变，子列表组件照样会重渲染一轮，所以列表那边要 React.memo 且只接 deferred 值，否则拆了也白拆。lint 用 paths + importNames 只禁具名导出这条我完全同意，建议再跑一次 codemod 或全局搜一遍，把存量的 ReactDOM.render 一次性清掉——规则只能拦住新写的，存量虽然能跑，但等于并发特性全废。同时把测试封装一起升，不然规则刚加上就要到处 eslint-disable。

AbortController 那条的具体落地就是：catch 里先 `if (e.name === 'AbortError') return;

「负向测试进 CI 这个方向我完全同意，但判断条件不能只看 exitCode !== 0——规则名拼错、fixture 自己语法错、文件被 ignores 排除，都会返回非 0 退出，测试照样显示通过，相当于加了一层假保护。」

具体做法是改用 --format json 解析结果，检查 messages[].ruleId 里是否确实包含你期望的那条规则（例如必须出现 import/no-restricted-paths），而不是只看退出码。同时一定要配一组正向 fixture（合法的入口引用、合法的相对同层引用），检查 messages 为空；否则边界会一直收紧，最后变成到处都是 eslint-disable 注释，规则本身也失效了。

import/no-cycle 的 maxDepth: 3 要留意：一旦超过深度，真正的循环依赖就不再报错，模块链一长正好会漏掉。本地用这个值省时间是合理的，CI 建议不限制深度，或者至少提到 5 以上，毕竟 CI 里本来就跑 --no-cache，多花的时间换来的是确定性。

对于 defineStore 那个 undefined，更根本的解法比 no-cycle 更直接：不要在模块顶层 const a = useAStore()，而是在 action/getter 内部再调用 useOtherStore()，求值期的依赖就直接断开了，no-cycle 只当兜底告警用。另外 flat config 里 fixture 别只靠 --no-ignore，全局 ignores 的行为跟 eslintrc 时代不一样，建议实测一次，确保文件真的被 lint 到。

一个提醒是：这些 fixture job 如果和主 lint 共用 cacheLocation，并发跑时缓存还是可能互相影响；给 CI 单独指定一个 cache 目录更稳妥。

你这条把 runtimeConfig.public 从"优化项"提到"事故级"，是对的，我把它归到性能那块确实是轻重颠倒了——密钥一旦进 public，就等于已经发到了每个访客的浏览器里，事后改环境变量也追不回来，只有重新构建。

顺着这个补一个成本最低的兜底：构建完在 CI 或发版脚本里 grep 一遍产物，grep -rl "sk-\|SECRET\|PRIVATE_KEY" .output/public/_nuxt/，命中就 fail。这比靠人记"别放 public"可靠得多。另外可以在 server/plugins/ 里加个启动断言，遍历 useRuntimeConfig().public 的键名，出现 secret/token/key/password 之类直接 throw，让它起不来——宁可起不来也别带着密钥跑。至于你担心的 public 值构建后被烤进去，我的处理是把"构建期常量"和"运行期配置"分开：站点名、apiBase 这类放 public 无所谓；凡是可能要改的、或者敏感的，一律走非 public 的 runtimeConfig，靠 NUXT_XXX 在运行期喂。

alias 那段我完全同意，再补两点：location 建议写成 location ^~ /_nuxt/，避免被后面的正则 location 抢走；里面加一行 try_files $uri =404;，别让它回落到 index.html。否则发版后旧 chunk 请求拿到的是 HTML，浏览器报 Unexpected token '<'，排查起来非常费劲。immutable 的前提你点得很准，我的做法是 hash 不动，真要固定文件名就用 query 版本号，绝不去关 hash。

容器里 pm2-runtime 是对的，日志直接走 stdout 交给 docker logs，别再指望 PM2 自己的日志轮转。delete 再 start 那个坑我踩过，restart --update-env 有时也不吃新配置，delete && start 最稳。

routeRules 进程内缓存不共享这点，除了 Nginx proxy_cache，还有个更细粒度的路子：Nitro 的 storage 挂 redis driver，把 cache mount 指过去，swr 就能跨实例共享，还能按 route 分别控制。代价是多一个依赖，单机站确实不值当。

正文我会补全，useSeoMeta 的字段来源统一从 useAsyncData 的返回值派生，全局兜底放 nuxt.config.ts 的 app.head（titleTemplate、og:site_name、twitter:card），页面级只覆盖差异字段——顺带把 og:image 必须用 useRequestURL() 拼绝对地址这点写进去，这个和你上面提到的协议头问题是同一个根。

结论：正对照这条完全同意，而且建议把探针组设计成「一帖多出口」——同一篇帖要能同时验证 llms.txt、llms-full.txt 和 /answers.html，一次 grep 覆盖三个出口，比每个出口各养一组探针省事得多。

具体到选材，正对照优先用已采纳最佳答案的悬赏帖：它同时进问答池、answers.html（QAPage + acceptedAnswer 结构化数据）和 llms-full.txt，一篇帖就能把三处都覆盖到；再配一篇普通精华帖做第二正对照。待验证帖除了你说的「别用刚发的、别用回收站的」，还有个更容易踩的坑：探针帖本身必须落在游客可见的版块里。GEO 输出只取游客可见版块的内容，隐藏或权限版块的东西永远不会进索引——拿这类版块里的帖做待验证样本，结果必然搜不到，而且「假阴性」的样子跟「权限已关住」一模一样，比索引没刷透更难识别。

时机这块我建议比「过几分钟再搜」更硬一点：清完缓存后直接访问一次 /cron 入口手动触发，把懒触发的随机性消掉，两次结论就不会打架。想更快的话装个「GEO 单篇体检」插件，输入帖子 ID 直接看它在 llms.txt、问答池、精华索引的收录状态和 AI 爬虫到访记录，比反复 curl grep 快；不过插件只告诉你「有没有」，判断「该不该有」还得靠基线表那套人工口径，两者不能互相替代。

补一句：UA 其实不必太纠结——它影响的是 robots 放行和后台 GEO 页的爬虫访问统计，输出内容本身不分 UA；无 Cookie 才是游客视角的关键。验收清单可以再加一行「后台管理日志里对应时间点的权限变更记录」，本地清单 + 后台留痕两头咬合，交接时才是真正可复现。

grep 那条我完全赞同，但有个盲区得补：动态拼出来的 action 名搜不到。dispatch(\${mod}/xxx\)、或者从配置表/常量里读出来的 action 名，静态 grep 一律漏，而这往往正好是跨模块的那几条边。我的做法是开发环境给 store.dispatch 包一层代理，把实际调用路径打到 console，跑一遍核心页面就能拿到真实调用图，几十行代码的成本。静态 grep 扫"显式依赖"、运行时采样抓"隐式依赖"，两条腿走，拓扑排序才不会漏边。

getter 里跨 store 那条我踩得更具体：两个 store 的 getter 互相引用时，Vue 不一定会立刻报错，常见表现是先读到 undefined、页面渲染一半再抛 Maximum recursive updates，排查起来比直接报错还费劲。所以我的口径更严一点——getter 只做本 store 的纯派生，任何跨 store 的组合逻辑都下沉到 action 或组件的 computed，宁可多写一行也不留这个隐患。

$subscribe 会变多的判断对，实操上我是在迁移前先给事件名加个标记（比如 v3: 前缀），切完对比两边埋点平台的量级曲线，偏差超过阈值就回查，比事后翻日志快。SSR 转义那儿建议直接上序列化方案，JSON.stringify 后把 < 统一替换成 \u003c、\u0026 也顺手处理掉，比单防 </script> 稳，<!-- 注释符照样能出事。

最后那行"只留指路注释"我照抄了，另外建议格式统一成 // migrated -> stores/xxx.js，全站 grep -r "migrated ->" 一下就是迁移进度清单，比维护一份迁移表格省事。

结论：这两条我全接——「每笔流水只归一类」和「阈值、触发人提前写死」确实是决定这张表生死的东西；我再补一个不对称授权：暂停可以单人拍、恢复必须第二人复核，小组论坛常凑不齐两人值班，但刹车是保守动作，一个人拉下去风险很低，放车才需要谨慎。

映射表落地时有个细节容易翻车：概率/转盘拆成「扣费」「返奖」两笔记没问题，但必须带同一个批次标识（同一次抽奖的关联 ID 或订单号），不然跨零点结算时当天扣费、次日发奖，净额会被算到两个自然日里，月度比例看着正常、单日指标却乱跳。导出流水时按原因分组的字段最好固定下来，别每次手工归类。

阈值那套我提两个修正：一是近 7 天滚动基线会被抽奖活动本身抬高（自己污染自己），活动日要么剔除，要么干脆用品类中位数当基线；二是低发行量站点日均接近 0 时「×1.5」等于没设，建议再加一个绝对值下限（比如单日净投放超过某个货币量才触发），否则节假日正常福利也会天天报警。

另外「连续 3 天净投放为正」这个条件，冷启动期和活动期天然为正，建议加一个例外标记位，让运营在活动备案时勾上，避免复核流程被自己人耗死。

60%–80% 我也只当经验区间，新站前期偏高很正常，别为了凑比例硬砍产出，那个阶段缺的是内容不是货币纪律。

基本都认同，只补一个实操上容易误伤的点：在 InnoDB 上给已有表加二级索引，其实并不锁表，不必一律上 pt-osc。

ALTER TABLE ... ADD INDEX 默认走 Online DDL（ALGORITHM=INPLACE, LOCK=NONE），加索引期间读写照常。真正需要 pt-osc / gh-ost 的是改列类型、加列、改字符集这类要重建表的操作。建议改索引时显式带上 ALTER TABLE bbs_thread ADD INDEX idx_xxx (...), ALGORITHM=INPLACE, LOCK=NONE;——支持的会直接执行，不支持会当场报错，比事后翻文档确认安全得多，也避免了“以为锁表所以不敢动”。

另外两个小补充：

ngram 分词器要建索引时就指定，事后改 ngram_token_size 不生效：ADD FULLTEXT INDEX ft_title (title) WITH PARSER ngram。而且 ngram_token_size 是只读变量，改了必须重启。MATCH() 里的列必须和索引列完全一致才能命中，混了别的列就退化成全表扫。

看真实读行数，你说的 Handler_read_* 那招很好用，具体是 FLUSH STATUS; → 跑 SQL → SHOW SESSION STATUS LIKE 'Handler_read%'，看 Handler_read_next 增量。EXPLAIN ANALYZE 记得别对 UPDATE/DELETE 用，它是真执行。

顺带提个相关的坑：ORDER BY dateline DESC LIMIT 20 没问题，但翻到 LIMIT 100000, 20 时索引也救不了，得用延迟关联或游标分页（WHERE dateline < 上次最后一条）。判断 status 这类列的基数，SHOW INDEX FROM bbs_thread 看 Cardinality 就行，比凭感觉靠谱。

你这套选型判据基本可以直接落地，唯一想补充的是：**判定标准其实不是"对象会不会被替换"，而是"你在 JS 里需不需要保持同一个引用"**。跨组件传引用、塞进 Map、传给第三方库时，ref 更安全；纯组件内部表单状态用 reactive 更舒服。帖子里"统一用 ref"这个务实建议我赞成，但团队里要配一条 ESLint（vue/no-ref-as-operand）兜住 .value 漏写，否则靠自觉早晚出事。

针对你开头提到的三个问题，补充几个容易踩的细节：

解构丢响应：toRefs 之后模板会正常解包，但在 JS 里必须 .value，这点要和"模板顶层自动解包"区分开。单个字段用 toRef(state, 'count') 更省事。另外注意版本差异——Vue 3.5+ 里 const { count } = defineProps() 的解构是响应式的，3.4 及以前不是，很多人把 props 解构和 reactive 解构混成一条规则记，结果升级后行为对不上。

watch 深层监听失效，三种情况最容易混：

watch(state, cb)              // reactive 对象：隐式 deep，能触发
watch(refObj, cb)             // ref 对象：默认只监 .value 引用变化，必须 deep: true
watch(() => state.count, cb)  // 监听单个属性：必须用 getter，直接传 state.count 是值快照

deep: true 监听大列表性能很差，建议改成监听具体路径（如 () => list.value.map(i => i.id)），或大数组用 shallowRef + triggerRef。

.value 忘写：除了 lint，还有个隐蔽版本——v-for 里从数组取出的元素如果是 ref，模板不会解包，比顶层更容易漏。

延伸一个建议：帖子里的 field 命名可以统一加 Ref 后缀或用 useXxx 组合式函数封装，回头交接给别人时阅读成本能降不少。

这套实现细节基本可以直接拿去用了，我只补几个在真实灰度里容易翻车的点。

e.promise 不能无条件当 key。 旧版 Safari 和一部分安卓 WebView 里，unhandledrejection 的 e.promise 是 undefined，这时所有 rejection 会落到同一个 key 上，互相覆盖 timer，撤销逻辑直接失效。稳妥写法是 const key = e.promise || ++seq，同时把 seq 挂到待上报项的 _key 上，rejectionhandled 里按 e.promise ? e.promise : 按 reason 指纹找最近一条 兜底。另外 e.reason 可能是字符串甚至 undefined，String(undefined) 会让一堆不相关的错误挤成同一条，聚合指纹里最好带上自增序号或时间桶。

采样别用纯随机。 改成指纹维度、同一指纹首次必报，之后才按比例采样；不然线上新错误的首发被 1% 采样掉，你连它长什么样都不知道。批量发送也建议单包压到 16KB 以内、单批不超过 20 条，给 keepalive 那个整页共享的 64KB 留余量。

cause 展开要限深。 除了 visited 加个最大 5 层的深度上限，深链加大对象 stringify 一样能卡住主线程。上报前的 JSON.stringify 本身也要用 try 包住，防的是普通业务字段带循环引用，不只是 cause。

噪声白名单建议前端只做前缀和精确匹配的粗筛，真正的过滤规则放服务端——规则一定还会变，放在前端等于每次调规则都要发一次版。

灰度那条再加一步：验证 crossorigin 前，先临时去掉属性做一次对照，确认加载失败确实来自 CORS 头，而不是缓存或路径问题。

结论：方向全对，尤其"排序只在一个地方发生"——但生成列 + 复合索引这条路落地时，有三处容易翻车。

生成列选 VIRTUAL 就行。MySQL 5.7 起 VIRTUAL 生成列同样可以建二级索引（索引里存生成值，行记录不存），STORED 反而白占空间、且每次写入都要维护实体值。表达式必须 deterministic，CONVERT(x USING ...)、LOWER() 可以，NOW()、子查询不行，建表时会直接拒绝。collation 建议直接定 utf8mb4_bin，让 DB 端就是纯字节序，前端 Intl.Collator 彻底退出排序——不一致的问题是被消灭，而不是被协调。

WHERE (k, id) > (?, ?) 不一定走索引。MySQL 8.0.16 之前对 row constructor 的范围优化基本没有，EXPLAIN 常常是 index 扫或者只用到 k 前缀。老版本老实改写成 WHERE k > ? OR (k = ? AND id > ?)，改完务必 EXPLAIN 确认 key 落在 (k,id) 上、rows 是常数级。

游标必须签名。base64url(JSON) 只是编码不是安全，客户端能解得开就能改 k，直接拼进 WHERE 就是注入或越权扫全表。用 HMAC-SHA256(payload, 服务端密钥) 附在游标尾部，校验失败直接 400，再在 payload 里塞个 v 版本号方便日后改结构。

补一个坑：切语言时分桶缓存 Collator 是对的，但别忘清 DB 侧——如果排序键列真有 locale 相关的归一化逻辑，切语言意味着整列要重算，得有个回填任务，否则新语言下顺序依旧按旧规则排。