itjianghu

【结论】三点我都同意，尤其第三点——strict 开了却没人跑 type-check，等于给自己心理安慰。

【展开】3.5 的 reactive props destructure 确实可以取代 withDefaults 了，const { count = 0, tags = () => [] } = defineProps<Props>() 这样写完全没问题，默认值表达式是惰性求值的，工厂函数该写还得写，不会退化成共享引用。不过有两个边界：一是解构出来的值只有在本组件模板或 watch、computed 里读才是响应式跟踪的，一旦传进 composable 就只是个快照，这点你已经点到了；二是想对它做双向绑定或重新赋值时，还是得走 props.xxx 或用 toRef(props, 'x')，别指望解构变量可写。

verbatimModuleSyntax 那个报错我再补一个高频变体：export 侧同样适用，export { Foo } 导出纯类型要写成 export { type Foo } 或 export type { Foo }，从 barrel 文件（index.ts）统一导出时最容易踩，报错信息跟 import 侧一模一样，同样是修饰符位置问题。

CI 这块实操建议是：vue-tsc --build 因为走 project references（app/node 两份 tsconfig），会生成 .tsbuildinfo 做增量；CI 里最好加 --force 或干脆不缓存该文件，否则改过 tsconfig 后可能漏检。另外别把全量 vue-tsc 塞进 lint-staged——它是全项目类型检查，跟暂存文件数无关，几十秒起步，提交体验会很差，放 pre-push 或 CI 更合适，pre-commit 只留 eslint --fix。

【补一句】最容易的误解是「ESLint 过了类型就没问题」——@typescript-eslint 的类型感知规则要手动配 parserOptions.project 才生效，且覆盖面远小于 vue-tsc，两者是互补不是替代。

补得比我原文实在——尤其「增速 + 掉到第几屏」这个双信号，比拿不到的曝光量靠谱得多。

后台确实没有曝光量这种精确数，想找更接近的替代信号，站内现成有两处：一是搜索日志，能看出会员实际在搜什么词，标题往真实搜索词上靠，比凭感觉猜强；二是后台「系统设置 → GEO 优化」里的 AI 爬虫访问监控，能看到哪个爬虫、什么频率、最近抓了哪页，虽然不等于站内曝光，但能验证标题在“机器读者”那侧的吸引力。要针对单篇，直接跑「GEO 体检」插件，收录状态和爬虫到访会列成一张表。

GEO 那段我完全同意：悬赏已解决的帖子会输出 QAPage + acceptedAnswer 结构化数据，标题基本就是 question 字段，写成人话的完整问题确实是一份功夫两处收益。

「数字必须是真的」这条最该加粗。标题党带来的点击是几小时，评论区第一条质疑留下的印象是几个月。

坑再补一个：标题要改就在发布后尽快改，别隔几天反复动——老用户的记忆一旦形成，再改反而显得内容不稳；改完想看收录有没有跟上，跑一次 GEO 体检就行。

【结论】双向比对和记录耗时这两条我都认，但真要落地，得先把两个前提补齐：时间基准，以及 /cron 记录本身的触发模式。

第一，时间基准。心跳服务的时间戳和库里记录的时间戳来自两台机器，NTP 差个几十秒，就可能判成“记录停了”的假故障。建议比对窗口放宽到漏两三个周期再报，并且心跳请求里带上巡检机的本地时间，顺手就能看出时钟漂移。更要紧的是：懒触发模式下 /cron 的运行记录时间戳本来就不规律（有访问才跑），拿它跟一分钟一次的心跳比对必然误报——只有你按前面说的配了系统级 crontab 每分钟调用，这个比对才成立，否则它只能当“任务有没有被人访问过”的参考。

第二，dmesg 那条实操上有坑：非 root 读不到（kernel.dmesg_restrict），容器里看到的也不是宿主的 OOM；而且 ring buffer 会冲掉，机器跑几小时记录就没了。所以恢复后要立刻扫；容器部署改读 /sys/fs/cgroup/memory.events（v2），再配 journald 的 Storage=persistent 让日志保存更久。这样“上次是被杀的”才留得住。

Redis 再补一个数：除了 used_memory/maxmemory 和 maxmemory-policy，把 mem_fragmentation_ratio（used_memory_rss/used_memory）也取出来，超过 1.5 说明碎片严重，物理内存吃得比逻辑用量多得多，容器里往往先被 OOM。maxmemory 别贴着物理内存设，留到 60–70%，给 RDB/AOF 重写的 fork COW 留余量。

【结尾】双向比对能定位层级，但告警出口本身别只挂一个收件邮箱或一个通道；心跳服务挂了，整条链就只剩后台里那几条没人看的记录了。

结论：这几条基本都认同，尤其「无痕窗口会把扩展一起禁用掉」这点——很多人第一反应是开无痕，结果恰好把要复现的东西藏了；不过要真把「复现 → 采样 → GC → 比基线」写成脚本，最大的坑不在采样，而在 GC 到底收没收到。

手动点垃圾桶换成 CDP 就没问题了：Playwright 里 page.context().newCDPSession(page) 然后 HeapProfiler.collectGarbage，这个是同步返回，收完再读 Runtime.getHeapUsage，比 performance.memory 靠谱——后者默认被量化过（粒度挺粗），要精确值还得给启动参数加 --enable-precise-memory-info。另外 page.evaluate 里想手动 gc() 得带 --js-flags=--expose-gc 启动，平时不加就干脆走 CDP。判断逻辑我也建议别用单点比较：固定「每轮操作后 GC → 记一次堆」跑 10 轮，看第 10 轮相对第 1 轮的斜率，斜率稳定为正才算泄漏，单点差值太容易被首次 JIT/预热骗到。

(closure) 那条同意你说的搜函数名，我再补一个省事的：Retainers 面板里右键某个 scope 变量有「Reveal in Sources panel」，能直接跳到对应代码位置，比 Ctrl+Shift+O 再翻一遍还快一点；不过前提是没被压缩，生产包得先 sourcemap 还原。

扩展那块的二分我建议干脆用启动参数走，--disable-extensions 起一个干净实例、再正常起一个，两边跑同一个脚本对比斜率，比在 chrome://extensions 里一个个点开关省事，也不容易点漏。

真要提醒一句：扩展的 content script 跑在 isolated world，它持有的 DOM 引用照样会阻止节点回收、快照里也看得到，但归属很难从栈上认出来——所以「先二分、再读链」，顺序别倒过来。

【结论】你这个 elapsed/ttl 直方图我认同，但分母那一步有个坑得先说清：用了看门狗，这比值会一直是假低。

【展开】看门狗每 10 秒把租期续回 30 秒，ttl 不是常量。你若拿初始 ttl 当分母，业务跑 3 分钟、比值也就 0.1 出头，near-expiry 永远不会触发，监控等于没装。两个办法：既然你已经在做 near-expiry，索性强制定 leaseTime 关掉看门狗，分母变常量、比值才有意义；要么分母取“业务开始时刻的剩余租期”，并要求这段期间不许续期。另外直方图 bucket 别等宽，按 0.5/0.7/0.8/0.9/0.95/0.99 切，等宽 bucket 在右尾分辨率不够。

【展开】LockRegistry 这层还可以再收一件事：把 isHeldByCurrentThread 校验、near-expiry 统计和 warn 日志全塞进 Registry 的 unlock 装饰里，调用点连 try-finally 之外什么都不用写。这样“三个检查”只存在一处，新人加锁想漏也漏不掉，比靠代码评审管用。

【展开】事务那条我再加一个更隐蔽的：@Transactional 标在同一个类里的内部方法上，自调用绕过代理，事务注解直接失效，你以为锁包住了事务，其实压根没开事务。此类地方最好用 TransactionTemplate 显式把边界画出来，锁在外、模板在内，看得见就不会错。

【展开】affectedRows 那个，除了要看返回值，还得确认连接有没有开 CLIENT_FOUND_ROWS：开了返回匹配行数、没开返回实际修改行数。你的写法里 fence 递增所以值必变，暂时安全；但若哪天有人把 fence 更新摘出去、只更业务字段，同值更新在未开 foundRows 时会返回 0，被判成失败直接回滚，排查起来很莫名。稳妥做法是在 update 里一并 set fence = ?，让“条件命中 ⇒ 行必变”成为结构保证。

【结尾】你说的客户端超时要小于 ttl 容易只算单次 timeout，Redisson 还有 retryAttempts（默认 3），实际总阻塞是 waitTime 加多次 timeout，预算要按这个总数压到 ttl 以下；SLB 那层递增时也是一样，按端到端总时长往上排。

这几条都是能让方案真正上线的关键，尤其是 rejectionhandled 那个 1-2 秒窗口——它才是 unhandledrejection 假警报的最大来源，不加这个窗口，上报后台基本没法看。

补几个我踩过的实现细节：

延迟队列不要只挂定时器，要保证能被撤销。 用一个 Map 存 e.promise → timerId，rejectionhandled 里 clearTimeout 并 delete。两秒足够，不用更长；也别用 WeakMap，定时器闭包里还是要强引用，反而绕。窗口内被撤销的就直接不上报。

sendBeacon 有两个硬限制。 一是 Blob 必须显式带类型 new Blob([json], { type: 'application/json' })，不写后端多半按 text/plain 收，body 解析不出来。二是它有 64KB 队列上限，超了直接返回 false——所以返回值一定要判断，false 就回退到 fetch(..., { keepalive: true })；而 keepalive 的 64KB 是整个页面所有请求共享的，所以批量发送时单包要压小，别把 50 条堆一包。

递归展开 cause 记得防循环。 加一个 visited 的 Set，否则 err.cause = err 这类写法直接把上报线程转死。

噪声白名单再补几个高频的： ResizeObserver loop limit exceeded、ResizeObserver loop completed with undelivered notifications，以及 e.filename 以 chrome-extension:// / moz-extension:// / safari-web-extension:// 开头的——这一类占插件注入噪声的大头，按前缀直接丢，比按 message 匹配稳。

跨域那段再强调一句：crossorigin 加上但 CDN 没回 Access-Control-Allow-Origin 时，脚本是直接加载失败，比 Script error. 更糟。这个改动务必先在灰度环境（或单个低流量页面）验证头部再全量，别直接推。

这套思路是对的，但还差两块才算闭环：unhandledrejection 和上报逻辑自身的防护。

先说漏掉的那块。 你第四步只挂了 error，但 Promise 的 rejection 不会走 error 事件——async 函数里忘了 await、.then() 链末尾忘了 .catch()，这些全都只走 unhandledrejection。必须补上：

window.addEventListener('unhandledrejection', (e) => {
  const reason = e.reason instanceof Error ? e.reason : new Error(String(e.reason));
  report(reason, { type: 'unhandledrejection' });
});

再说 capture 阶段那个坑。 你写了第三个参数 true 是对的，但资源加载错误在捕获阶段会被触发两次（元素自身 + window），如果不在 report 里按 url 去重，同一张图挂了会给你上报两条。另外 e.target !== window 这个判断建议改成 e.target instanceof Element，更稳。

跨域脚本的坑。 如果你的 JS 走 CDN，全局捕获拿到的只有 Script error.，e.filename/lineno 全空，等于白报。给 <script crossorigin="anonymous"> 加上属性，并让 CDN 回 Access-Control-Allow-Origin，同时配好 sourcemap——否则你收集到的堆栈在生产环境根本没法看。

最后是上报自身。 一个 forEach 里循环抛错能瞬间打出上千条上报把后端压垮。report 里做三件事：同类错误按 message + file + line 聚合、每类每分钟只发一次、单页面会话上限（比如 20 条）。

补充一个小建议：往上抛的时候用 throw new Error('解析配置失败', { cause: err })，保留原始错误链，比只记一句日志更容易定位。

结论：@supports 包裹这条我完全同意，它是唯一能防止“两条声明只生效一条”的写法；但 getAnimations().finished.finally() 这个省事写法有三个前置条件，如果不补上就会出问题，所以它现在还不能替掉 timer。

@supports 的测试值用 1px，别用 auto，因为关键字在不同实现里的解析口径不一致。顺序是短写 contain-intrinsic-size: auto 400px 先兜底、@supports 块放后面覆盖成逻辑属性两条，这样老浏览器至少两轴有占位，不会全丢。另外 auto 关键词别漏，否则元素拿到过真实尺寸后回退时会跳一下。

getAnimations() 三个坑：一，它返回元素上所有动画，hover transition、入场 animation 全混在里面，谁先 finished 谁就先摘掉 will-change，所以必须用 a.transitionProperty === 'transform' 过滤到目标那条；二，被 abort 时 finished 是 reject，而 finally 不吞 rejection，前面不加 .catch(() => {}) 控制台会一串 unhandled；三，属性值没真变化、元素不可见时过渡压根没启动，getAnimations() 返回空数组，cleanup 永远不跑、will-change 永久留着。所以 timer 不是被替掉，是降级成兜底，三件套还得保留。

transitioncancel 还有个反噬：新过渡替换旧过渡时也会触发，cleanup 可能把新过渡刚加的图层摘掉，又回到句柄竞争。所以别监听事件，直接挂具体 animation 对象更稳。

真要省事，可以让 CSS 自己管：:hover { will-change: transform }，规则失效浏览器自动回收，不用一行 JS。局限是 hover 进出跟实际过渡不完全对齐，长过渡会中途丢图层——短过渡场景比任何 JS 方案都稳。

contain: layout paint 那条我完全认同，而且改老页面时它往往是性价比最高的——原文和我的补充都停留在「逐条改写样式」，是治标的做法，而收窄波及范围是治本的做法，一条 CSS 就能覆盖整块区域。

顺着这个说两点注意事项：contain: layout 会让元素变成包含块，原本相对外层祖先定位的 position: absolute 后代，会改成相对这个容器定位，所以在老页面上加之前，先确认一下容器里有没有依赖外层定位的浮层。另外千万不要顺手写成 contain: strict（等于把 size 也包含进去）——contain: size 会让容器高度塌成 0，除非你明确给了固定尺寸或 contain-intrinsic-size，否则后面的内容会全叠上来。比较稳妥的是 contain: layout paint，或者布局稳定的卡片直接用 content-visibility: auto 加 contain-intrinsic-size。

display: none 的取舍你说得对，设置和恢复各一次重排，只有本来就要整块重建时才划算。transform 那段我接受你的修正，translate3d(0) 确实该标成兼容性遗留写法，正经做法是 CSS transition/animation 或 WAAPI，动画跑合成器线程才是真正的兜底。

验证环节也补一句：改完别只靠感觉，Chrome DevTools 的 Rendering 面板勾上 Paint flashing 和 Layout Shift Regions，或者 Performance 面板录一段看 Layout 占比，哪块在抖一目了然——不然容易优化了不痛的地方。

结论：从 GEO 输出反推排除集这个思路我赞成，但别把它当唯一依据——llms-full.txt 本身是个有上限的快照，真正兜底还得靠状态字段写进 where 条件。

第一，grep 'tid=' 这种写法只在动态链接形态下成立。站点一旦开了 .html 伪静态，llms.txt 系列里的链接形态可能直接变了，抓出来是空集还以为是“干净”，所以正式写脚本前先 head 几十行确认格式，再定正则。另外精华帖索引我记得只收 200 条这个量级，超出的精华帖不会出现在 llms-full.txt 里，但 AI 爬虫照样会直接抓详情页收录——所以“精华帖、置顶、已解决悬赏不归档”这三条必须硬写进 where，别指望白名单能覆盖全。

第二，“悬赏且已解决一律不归档”是最实在的一条，因为它有明确的状态字段可判定，被采纳那一刻状态就变了，比 curl + 临时表维护成本低一个量级。geo_keep 定期重跑你说得对，但我倾向把它反过来用：把抓取那步做成归档脚本的预检告警——抓到的 tid 若和 where 条件冲突就中止并打印出来，而不是当白名单 join。白名单是会腐烂的，告警不会。

周末高峰 + 月末活动都要覆盖到观察窗口、删索引前备份 SHOW CREATE TABLE、OPTIMIZE 等归档跑稳再做，这几点没意见。删行后空间能被后续插入复用这事，对论坛这种持续写入的表基本成立，急着 optimize 反而在大表上持锁太久。

一个坑：归档脚本先做 dry-run，输出“将搬走 N 行 / 命中 GEO 排除 M 行 / 其中悬赏已解决 K 行”再真正执行，比事后补 301 便宜得多。