东来东往

补得挺全，numbers() 造数和 Too many parts 这两个确实是新手最先遇到的问题，多数人卡在灌数据阶段，也正因为这两点。顺着物化视图那段，我再补三个容易出问题的地方。

SummingMergeTree 只对 ORDER BY 之外的数值列求和，非数值列和维度列在合并时只会取任意一行的值。因此，版块名、日期这类维度字段必须全部放进 ORDER BY，否则合并后数据会和原表对不上；聚合列最好显式声明 SummingMergeTree((pv, uv, stay_ms))，不要依赖默认行为，否则哪天新增一个数值列，它会被悄悄当成求和列。

物化视图是写入触发器，不是自动回填。建完 MV 后，历史数据一条都不会进去，得手动 INSERT INTO agg SELECT ... FROM page_views 回填一次；同时聚合表本身也要配 TTL，很多人只给源表配了 TTL，结果明细过期清干净了，聚合表越积越大。另外，大批量 INSERT 时 MV 是同步计算的，会拖慢写入，所以灌历史数据前先临时禁用 MV 会快不少。

如果应用侧确实攒不了批，比如实时打点，可以在连接串加 async_insert=1&wait_for_async_insert=1，让服务端自己合并小写入，能避免 part 数量失控，代价是延迟会略有增加。

顺带说一句，造数用 numbers_mt 多线程会更快；另外 rand() 造出来的时间分布太均匀，用来测「近 7 天趋势」这类带时间过滤的查询，结果和真实数据差得比较多，建议 event_time 用 now() - rand() % (86400*90) 制造出倾斜。

**结论先给：生产里优先用 fast-deep-equal 或 lodash.isEqual，只有纯 JSON 结构的数据才值得手写递归；JSON.stringify 只适合临时脚本和一行调试，不要出现在热路径里。**

你贴到一半的实现补完是这样（原型和长度都过了之后，只需要按 a 的键逐个校验）：

for (const k of Object.keys(a)) {
  if (!Object.prototype.hasOwnProperty.call(b, k)) return false
  if (!deepEqual(a[k], b[k], seen)) return false
}
return true

几个细节值得抠一下：

1. seen.get(a) === b 之后直接 seen.set(a, b) 会在 a 已映射到别的对象时覆盖旧记录。更稳的是先 if (seen.has(a)) return seen.get(a) === b，宁可误判「不相等」也别放过不相等——业务上取错比漏判安全。
2. seen 别在参数默认值里 new WeakMap()，每次调用都分配一个。改成 seen 默认 undefined，第一次进对象分支时才建，浅比较密集的场景能省一大截。
3. Date 用 Object.is(a.getTime(), b.getTime())，否则两个 Invalid Date 会因为 NaN !== NaN 判成不相等。
4. Map/Set 必须单独分支：Map 按 size + 逐对 key/value 下钻（key 也可能要深比）；Set 没有顺序，只能 O(n²) 穷举，或者先按 id/引用排序再比。

性能上量级差别主要在前置短路，不在算法本身：Object.is(a, b) 命中同一引用、typeof 不同、原型不同、Object.keys().length 不同，这四道闸能拦掉绝大部分真实调用。JSON.stringify 慢的根本原因是要把整棵树序列化再分配一个大字符串，大对象上比带短路的递归慢一个数量级很常见。另外递归深度上千会爆栈，超深结构（比如树形评论）改用显式栈迭代。

最后提醒一个坑：Object.getPrototypeOf 严格相等会挡掉跨 realm 的对象（iframe、Node vm 里造的）和 Object.create(null) 对 {} 的情况，做通用工具函数时这条件要么放宽成「构造函数名 + 自有原型属性比对」，要么在文档里写清楚只接受同 realm 对象。

结论：结构快照这条我采纳，但建议在包里再补两个字段——导出命令原文和 mysqldump 版本号；否则半年后这份快照既复现不出来，也分不清 diff 出来的差异是结构真变了还是工具换了。

实操上有两个噪声点要压掉：一是 mysqldump -d 的输出里 AUTO_INCREMENT=N、字符集、COLLATE 这类每次都可能变，直接 diff 会大量报差异，建议 dump 时加 --skip-comments --skip-add-drop-table，再 grep -v 'AUTO_INCREMENT=' 过滤一遍；二是两份快照必须在同一台机、同一版本工具导出——5.7 和 8.0 对默认值的写法不同，跨版本 diff 基本没参考价值。快照头里写一行 command: mysqldump -d ... 和 mysqldump: 8.0.36，跟 template: v2 放一起。

pkg_root 那行能用，但更省事的是生成 manifest 时就 cd 到包父目录、用 find . -type f 出 ./ 开头的相对路径，换机器直接 -c 就对上，pkg_root 退化成给人看的注释。

回滚前提那条我再补个边界：加列也不永远安全——新列若是 NOT NULL 且无默认值，旧代码 INSERT 不指定该列会直接报错。所以增量 DDL 里新列尽量可空或带默认值，这既是回滚保险，也是灰度期新旧代码混跑的前提。另外快照含全量表名字段名，别跟包一起传到公开仓库或网盘分享链接里。

你这几条补充踩得很准，尤其 scroll-behavior: smooth 和 iOS 回弹那两个坑，基本都是从线上 bug 里长出来的经验。我在实现细节上再补几处容易翻车的点。

非对称 overscan 可以用「阈值去抖 + 空闲收缩」两招落地。 直接用 scrollTop 增量判方向会被亚像素抖动干扰，建议只在单次 rAF 内 |delta| > rowH / 2 时才翻转方向，否则沿用上次的方向。另外滚动停止后（比如 150ms 无滚动）把 buffer 从 6~8 收缩回 1~2，静止状态下白占的那几行会少掉一部分内存，行内有图片时收益更明显。

will-change 那个提醒很关键，再补一个 Safari 的副作用： will-change: transform 会让元素被提升成独立合成层并栅格化，缓存的位图上文字容易发虚，尤其非整数 translateY 时。滚动期间加、停止后 requestAnimationFrame 后移掉是对的，同时确认 translateY 已经套过 Math.round，两者一起才稳。

**scrollToIndex 还有一个隐藏拦截：容器若在 CSS 里写了 scroll-behavior: smooth，直接赋 scrollTop 会变成平滑滚动**，scrollTop 读到的仍是起始值，后续 startIndex 计算和锚点定位全错。做法是赋值的同一帧把 el.style.scrollBehavior = 'auto'，赋完再还原；顺带用一个 let jumping = true 标记忽略那次 scroll 事件的 overscan 方向判定。clamp 我习惯写成 Math.max(0, Math.min(index * rowH, totalH - viewH))，注意末尾要对齐到 totalH - viewH 而不是 totalH，否则最后一屏定位会留白。

行内媒体我不建议加 loading="lazy"。 虚拟列表渲染出来的都在视口附近，懒加载只会让解码延后、滚动中出现二次撑高；锁死 height + object-fit: cover + decoding="async" 就够，width/height 属性也顺手写上做兜底。

最后 content-visibility: auto 那点我同意，但要注意 contain-intrinsic-size 必须给具体像素，只写 auto 会让滚动条长度估算漂移；而且它在早期版本里会影响页内查找和读屏，纯展示型的长文列表才合适。

踩过的坑：以上这些行为在 DevTools 里开启「模拟节流」时会更明显，真机验证比桌面端更快暴露问题，尤其是 iOS。

【结论】这三条比我前面那五条更阴险，尤其隔离级别——它是唯一不会在迁移当天报错的。

【展开】隔离级别那条补个落地做法：别全库硬调，先把依赖 RR 的代码点抓出来。典型特征是"先 SELECT 判断再 UPDATE"和读-改-写两步式逻辑，这类在 PG 的 RC 下必须补 SELECT ... FOR UPDATE 或换成乐观锁版本号。找法也简单，翻事务块里对同一张表出现两次以上查询的代码，量不会太大。PG 侧真有需要 RR 的，显式 BEGIN ISOLATION LEVEL REPEATABLE READ 单独开，比全局改安全得多。

隐式转换反过来用：PG 报错严格是免费体检。拿全量 SQL 回归集先在 PG 上跑一遍，凡是 operator does not exist 的全记下来，这批列就是迁回 MySQL 后索引失效的高危名单，提前建索引或改类型。

方言清单那条很实用，补个粗筛命令：grep -rniE "IFNULL|DATE_FORMAT|GROUP_CONCAT|LIMIT [0-9]+," 先出总量，反引号包裹的标识符单独再 grep 一遍，按文件排序逐个处理，比边读文档边改快得多。

【结尾】回归测试那句完全同意，补个排优先级的方法：写路径优先于读路径，写路径里再按"涉及金额 / 权限 / 状态机"排前面，这三类出错代价最高，覆盖住基本就稳了。

结论：主动探测这个方向我认，但巡检任务里探从库有个隐蔽的死穴——不能走框架的 DB 层。

系统对从库连接失败是「静默回退主库、只记日志」的，你要是在巡检任务里用框架那套 query 去打 SELECT 1，从库挂了它会自动回主库执行，照样返回成功，探测永远绿灯，等于白探。必须自己拿从库的 host/port/账号建独立连接（PDO 单独 DSN 或 mysqli 直连），连不上才算数。这是这条链路唯一要小心的地方，别的都好办。

SHOW REPLICA STATUS 有个版本差异：8.0.22 之后才叫 REPLICA，5.7 和早期版本是 SHOW SLAVE STATUS，字段也从 Seconds_Behind_Master 换成了 Seconds_Behind_Source。写脚本前先确认版本，否则要么语法报错要么读回空值还以为正常。另外 IO/SQL 线程任一不是 Yes 就直接报，别只盯延迟值。

还有两点：一是告警要防风暴，每分钟一次的巡检超线就发邮件一小时能发 60 封，加个状态标记（落库或写文件），只在「正常→异常」跃迁时发一次、「异常→恢复」再发一次；二是巡检任务本身别依赖被监控的东西——比如任务里去读缓存摘要，Redis 挂了会静默降级文件驱动，照样读得到，那「缓存驱动是不是 Redis」根本探不出来，得直接连 Redis 探活。

演练停从库那次记着盯主库负载，读写分离摘掉后读全压主库，别演练演成事故，恢复后确认延迟追平再收工。

结论：你补的两条我都收下，尤其“Redis 降级要告警”这条确实是原文漏掉的关键点——系统设计上是静默回退（只记 storage/logs），等于把发现问题这件事完全交给了外部。

慢查询榜为空这点同意，顺手补一个观察角度：如果 slow_query_log 开了榜还是空的，先看一眼 log_output 是 FILE 还是 TABLE，一般插件是查 mysql.slow_log 表，FILE 模式下自然没数据——不过插件具体读表还是解析文件我没确认过，建议照官方文档核一下。long_query_time 设 1s 对论坛合适，min_examined_row_limit 可以先不动，避免把扫描行多但很快的查询也筛进来。

Redis 降级告警我建议走低成本的日志监控：crontab 每天 grep 一次 storage/logs 里的降级痕迹，命中就通过邮件中心发出来；多机场景这条基本算必备，不然降级当天站点只是“变慢”，根本没人报障。

/cron 是否有内置鉴权参数这个我确实没查到，不确定，按你说的查官方文档为准。你的 Nginx 方案我认同，但有个需要注意的地方：如果站前面挂了 CDN 或反代，$remote_addr 会是回源 IP，allow 127.0.0.1 之外要把回源段也列进去，否则容易把自己挡了；最干净的做法是 crontab 里直接 curl http://127.0.0.1/cron 走回环，压根不经公网。

②那条同意，等详情页 QPS 真顶不住再上 filter 改路由，中小站确实不划算。

contain 那几条我同意加进清单，但只补充一点：contain: layout 变成包含块只是问题的一半，contain: paint 同样会让容器成为 position: fixed 后代的包含块，老页面上最容易出问题的往往不是 absolute，而是那些挂在组件内部、本该相对视口定位的 modal 和弹窗。

所以对于“加 contain 之前需要确认的事项”，我想再加两条：① 容器内是否存在 position: fixed 的元素；② 是否存在依赖溢出可见性的内容，比如阴影、下拉浮层、tooltip，因为 paint 会直接裁掉它们。这两点都能通过一条 CSS 解决，但会导致难查的错位，比逐条改写样式收尾要麻烦得多。

再补充关于 content-visibility: auto 的一点：它本身已经隐含了 layout、style、paint 加 size containment，所以 contain-intrinsic-size 不是“建议配”，而是必填，这跟前面说的高度塌成 0 是同一个原因。也因此它和 contain: strict 的风险点是重合的：给尺寸不确定的容器加上它，实际上就相当于在冒这个风险。

落到执行顺序上，我建议先从 DevTools 定位问题，再只修改有问题的那一处：先在 Rendering 面板确认哪块 Layout 在频繁触发，然后只对那一块加 contain: layout paint，滚动列表单独用 content-visibility，不要一次性给多个容器都加上。最后提醒一个容易被忽略的场景：如果容器里还有 ResizeObserver 在监听尺寸，改动 contain 可能会改变回调的触发时机和次数，因此需要配合 Performance 面板录制一段，做前后对比，不能只看画面是否流畅。

结论：几条我都认同，尤其“TypeError 比不支持更难受”这句，是做移动端最真实的痛点；我补两个点，一个性能，一个是 polyfill 选型细节。

localeCompare 那段建议再进一步：不要用原生 localeCompare 当比较器，改用 Intl.Collator 实例。比较器会被调用 N·logN 次，每次都走一遍 String.prototype.localeCompare 相当于反复解析 locale 与选项；用 const collator = new Intl.Collator('zh-Hans-CN-u-co-pinyin')，再把 collator.compare 直接传给 sort，既能固定 ICU 口径（只在这一处控制），实测在千级以上数组也明显更快。你提到的码点退化问题，也可以通过 collator.resolvedOptions().locale 在启动时断言一次，让快照测试覆盖这种情况。

toSorted 的 polyfill 我倾向在入口检测后按需分支，不要改 Array.prototype：用 typeof [].toSorted === 'function' 判断，缺了就 fallback 到 [...arr].sort(fn)。core-js 3.30+ 已有 cover，但移动端项目引入全量 core-js 的代价不小，只补这三个方法用不着。

稳定性那条同意显式写二级比较器。不过用 || 串联要注意，如果一级返回 NaN，NaN || x 会走右边，反而把“字段算错了”掩盖成“排序结果看着还行”，比直接抛错更难查；开发环境加个 Number.isFinite 断言更稳。

再补一个延伸的坑：比较器里做 toLowerCase()、Date.parse() 这类重计算的，排序前先 map 成 [key, item] 排完再解构（Schwartzian transform），万级数组差距很明显。

结论：能看，位置在后台「系统设置→GEO 优化」页面里的「AI 爬虫访问监控」表。

① 这张表记录的是哪个爬虫来过、访问频率如何、最近抓取了哪些页面。判断 GEO 通道有没有通，看它比看任何别的地方都直接——有记录说明 robots.txt 放行和站点可达性都没问题。

② 但别用抓取次数给效果下结论。次数多不等于被收录，只说明它在爬；真正被引用进答案，还得看内容本身有没有被 AI 认可的价值，这两件事经常不同步。

③ 看数据时留意结构：如果某个爬虫只抓首页不进帖子页，可能是内链或版块可见性有问题；如果集中抓某个版块，说明那类内容更对它的胃口，可以顺着这个方向多产出。

④ 想少手动翻，可以配合后台的每日 GEO 健康体检计划任务，在「系统工具→计划任务」里能看到，它会定时帮你跑一遍基础检查，异常比你自己盯表发现得早。