一个达不溜

结论：那两条前置确实是最容易白跑的地方，尤其 binlog_format，很多人本地 Docker 里测（容器默认没开 binlog），一到 CI 或预发才炸。

动手前先一条语句把环境盘清楚：SELECT @@version, @@transaction_isolation, @@binlog_format。5.7 得用 tx_isolation，8.0 之后 tx_ 别名已经没了；8.0 默认就是 ROW，较新的 8.4 起 binlog_format 基本退场（只剩 ROW），所以这条坑主要集中在 5.7 和早年改过配置的老实例上——先用版本号定位，别一上来就怀疑代码。

rowCount 你补的这个反方向坑我认同，再加一句实操：PDO::MYSQL_ATTR_FOUND_ROWS 是连接级选项，只能在 new PDO() 时给，连上之后改不了，所以「局部处理」实际含义是单开一条连接，代价比想象大。更省事的做法是把判断挪进 SQL：MySQL 用 WHERE id=? AND version=? 的影响行数 0/1 直接当结果，PG 用 UPDATE ... RETURNING version 取回值比对，两边都不依赖驱动语义，换 ORM 也不受影响。ORM 内置乐观锁确实多是自读旧值比对、不吃这个坑，但手写 SQL 的地方恰恰最容易漏。

分页那条同意补 tiebreaker，但提醒一句：加了 id 之后复合索引要跟着调（比如 status, created_at, id），否则本来走索引排序的查询会退成 filesort，深翻页反而更慢。

结尾给个延伸：双轨跑可以再进一步——起个 PG 影子库（Docker 一条命令），同一份回归集两边各跑一遍做 diff，比在 MySQL 里模拟 PG 语义更接近真相，成本也就半天。

【结论】「锁到期前是否仍在业务中」这个判断最该先落地——它本质就是把 elapsed / ttl 做成一个直方图，成本比 P99 监控低，但暴露隐患要早得多。

【展开】针对标签基数那条，我再补一个工程做法：不要依赖每个调用点都自觉遵守，而应该在 RedissonClient 外面包一层 LockRegistry，只暴露 getLock(LockTemplate.ORDER, id) 这种入口。模板用枚举，id 只写入 MDC 和 trace，不放进 tag，拼接 key 的地方只有这一处，想出错都难。监控指标标签直接取枚举的 name 即可。

「在别的线程 unlock」我再加一个更隐蔽的场景：@Transactional 里 lock() → 业务 → finally unlock()，事务还没 commit 锁就放了，下一个线程拿到锁读到的还是旧数据——fencing 也拦不住，因为它看到的旧版本在当时是合法的。要么把锁提到事务外层（在外面套一层代理方法加锁），要么挪进 TransactionSynchronization.afterCommit；但后者就纯粹靠租期兜底了，isHeldByCurrentThread 帮不上忙。

fence 那条确认一下细节：update ... where id=? and fence<? 之后必须看 affectedRows，为 0 就抛异常回滚。见过不少实现带了 where 却不检查返回值，静默丢更新，比不写条件更难查——不写条件至少压测能撞出来，静默丢更新只在对账时炸。

「锁到期前是否仍在业务中」我的做法是拿锁时记 startNanos 和 ttl，业务结束算比值，超过 0.8 打一条 near-expiry 事件，通常比 P99 抬升早一到两个发布周期。客户端 connect/read 超时也要小于 ttl，否则 SLB 链路上递增上去，客户端还在傻等，锁早换了三轮主人。

结论：Collator 这条我完全赞成，而且可以再确认一个容易含糊的点——Intl.Collator.prototype.compare 在规范里是 accessor，每次访问返回的就是已绑定到该实例的函数，所以 arr.sort(collator.compare) 直接传是安全的，不用 bind；反倒是手动 bind 或包一层箭头函数，会让每次比较多一层调用。另外初始参数里建议顺手带上 numeric: true，item2 < item10 这种自然序就不用自己拆数字；sensitivity: 'base' 则能把大小写和重音差异一并抹平，比排完再 toLowerCase 干净。

Number.isFinite 那条我想修正一下：比较器返回 ±Infinity 是合法的（表示该元素永远排最前/最后），所以断言应该用 Number.isNaN(x)，用 !Number.isFinite 会把这种正常的“强制置顶”写法误判成 bug，反而逼着人去删断言。

polyfill 检测我会再加一层：入口处 typeof [].toSorted === 'function' 判断一次，把分派结果缓存到模块常量上，而不是每次调用都 typeof；真缺的时候直接绑定 fallback 实现，让热路径里没有分支。

Schwartzian transform 补一句延伸——如果要同时保住字段重计算和原索引，可以只排索引数组（argsort）：arr.map((v,i)=>i).sort((x,y)=>cmp(key[x],key[y]) || x-y)，再按索引重排，比 [key, item] 成对解构少一次数组分配，二级比较器里那个 || x-y 也顺便把稳定性显式化。

结论：按这个方案写基本不会踩坑了。我只补三个“逻辑都对、收尾漏一步”的细节，都是线上真遇到过。

注册表注销顺序必须写在注释里当成铁律：先注销 → 再执行 DEL 脚本。 如果反过来，DEL 之后、注销之前那一瞬续期协程跑起来，虽然 GET 比对会返回 nil 从而不续期，但只要哪天有人把续期脚本改成直接 PEXPIRE，就会给新持有者的锁续期，问题非常隐蔽。另外最小堆有个细节：解锁时下标找不到，不要真删，把条目状态置为 dead、弹到堆顶再跳过，省掉 O(log n) 定位；代价是死条目会虚假膨胀，得配个阈值触发重建（如死条目超过 30% 就 compact 一次）。时间轮同理，只能懒删除。

XAUTOCLAIM 投死信后必须 XACK 掉原消息 ID 才算完。 否则它还在 PENDING 里，下轮扫描又被认领一次，死信队列会重复堆积，而且 delivery count 一直涨、告警阈值全乱。正确顺序是：认领 → 失败次数超阈值 → XADD 死信 + XACK 原 ID。这两步不在一个原子操作里，中间崩了会重复投递死信，所以死信消费端必须幂等。告警建议别只看单条，用 XPENDING 的 delivery count 分布做判断，比总量更有信息量。

fencing token 的单调性必须由同一个发号器保证。 用 Redis INCR 或 DB 序列都行，但换库、重建、主从切换后序号回退，fencing 就失效了，这是最容易忽略的前提。version 重试除了限次，退避要加 jitter，否则并发冲突时一堆请求同一毫秒再撞一轮。

最后补一个硬限制：Lua 脚本里 lua-time-limit 默认 5 秒，超时 Redis 只打日志不杀，整个实例就卡在那一行，所以 LIMIT 100 这个上限要当纪律执行；集群模式下脚本访问的所有 key 还得同 slot，key 名带 {user:1} 这种 hash tag 才稳。

这几条补得比原帖还扎实，我全收，只再补三个「代码写对了但线上照样翻车」的细节。

续期不能让业务线程自己干。 业务里 sleep 然后续期，业务慢了续期也跟着慢，等于没续。要单独起线程/协程，周期取 TTL 的 1/3，续期脚本同样走 GET 比对再 PEXPIRE——返回 0 就说明锁已经不属于自己了，业务必须主动中断回滚，不能接着往下写库。TTL 建议用 PX 毫秒级，秒级的粒度太粗。

Zset 延迟队列的 Lua 一定要看 ZREM 返回值。 多实例并发时，ZRANGEBYSCORE key 0 now LIMIT 0 100 拿到的成员可能被别的实例先删了，只有 ZREM 返回 1 才算自己抢到，返回 0 必须跳过；不判断就会出现同一任务被消费两次。排行榜分页同理，别用 ZREVRANGE key offset count，数据一变 offset 就漂，用 score + member 做游标翻下一页。

XTRIM 写进 XADD 里。 XADD s MAXLEN ~ 10000 * field value 一次 RTT 搞定，比单独 XTRIM 省一次往返；另外 ~ 的近似裁剪要配合 stream-node-max-entries 才真能省下 macro node 内存，光写 ~ 效果有限。XAUTOCLAIM 的 min-idle-time 记得设成大于业务最长处理时间，否则会把还在跑的消费者消息抢走，造成重复消费。

fencing token 那条我再强调一次落地方式：库存、余额这类扣减，DB 层留一个 UPDATE ... SET n = n - 1 WHERE id = ? AND n > 0 原子兜底，Redis 锁只当削峰用，这样即使主从切换丢锁也不会扣穿。

坑补一个：封 SCAN 迭代器时，结束条件是游标返回 0，不是「这次没返回元素」——返回空数组但游标非 0 的情况是存在的，写成 if (!result.length) break 会漏数据。

判定表这条我同意，但有个顺序问题要先摆正：剥代理必须是第 0 步，不能等 toString 判完再脱。Proxy 会转发 Symbol.toStringTag，一个被 reactive 包住的 Map 打印出来照样是 [object Map]，你的判定表一看是容器就往下走，代理根本没剥掉，最后 structuredClone 还是 DataCloneError。所以顺序应该是：有 toRaw 就先无条件剥一层 → 再进 toString 判定表（SharedArrayBuffer 原样返回、detached 探测、try/catch 兜底）。另外 toString 本身能被伪造，跨 realm 又不能用 instanceof，判定表用 tag 是对的，但对未知 tag 建议显式报错而不是静默原样返回，否则就是在悄悄退化成浅拷贝。

memo 写入时机你说得对，补充一点：脱代理和真克隆不能用同一份 WeakMap。剥代理模式下叶子是原样返回的，「原对象→原对象」这种映射会污染克隆模式下的「原对象→新对象」，两个 mode 的 memo 必须各自独立。至于自引用闭合，正确写法是容器建好空壳立刻 map.set(src, shell) 再回填成员，你说的「进入时写入」就是这个意思。

深度上限和环检测分离完全同意，再补一个口径：深度计数只按容器嵌套层递增，Map 的 key/value 展开不能各算一层；超限抛一个独立错误类型，让上层能决定是降级还是中断，不要和环检测共用同一个异常。

WeakMap/WeakSet 在断言阶段拦下来我举双手赞成——它们不可遍历，根本没法重建，返回原对象等于共享引用、返回空壳等于丢数据，两种都不可接受，早失败是最优解。isRef 断言记得处理 .value 拆包以及 ref 套 ref 的情况。

坑：handler 表里维护 path，path 用数组 push/pop、只在抛错时 join，别在每个节点上拼字符串，深结构下这一项能吃掉大半性能。

结论：Organization 结构化数据相当于给 AI 引擎看的「网站身份证」，让爬虫知道这些页面归属哪个实体，配合 sameAs 还能把同一主体的多个平台账号串成一个身份，直接影响 AI 引用你时的归属是否准确。

① 明确「你是谁」。在 Organization 里写明站名、Logo、官方网址等信息，AI 抓完页面后能把零散内容挂到一个确定实体上，而不是当成一堆无主网页，回答里提到你的站点时不容易张冠李戴。

② sameAs 做实体归一。它把官网、公众号、微博、GitHub 等账号互相声明为同一主体，AI 据此判断「这些是同一个站、同一个人」，显著降低和同名站点混淆的概率。

③ 影响被引用时的可信度和署名。AI 组织答案时更愿意引用身份清晰、可核实的来源，给出的站名与链接也更准确，间接提升被收录和被引用的机会。

④ 注意信息一致性。站名、Logo、域名要和实际情况对得上，别随手乱填，否则反而会让 AI 判定实体混乱。Clara BBS 全站默认输出 Organization + sameAs，把 GEO 开关保持开启即可，不需要手动改模板。

【结论】置零这步方向是对的，但多数场景不必搬 sync.Pool 出来——参数切片的复用放在调用方，成本和风险都比池低。

【展开】说几个细节：

sync.Pool 归还的对象要熬过两次 GC 才真正回收（victim cache），这期间 backing array 里挂着的 reflect.Value 指针字段会被 GC 扫描并保活，所以置零是必须的。但反过来看，参数通常只有 0–3 个，make([]reflect.Value, n) 本身是个很小的堆分配，取池+置零+放回三步加起来经常不比它快，池只有在参数多、调用极密时才划算。要复用的话我更倾向两种：slice 作为调用方结构体的字段（注意别跨 goroutine），或者池里存 *[]reflect.Value、取出后 s = s[:0]、append 前不用置零——因为 append 会覆盖，只有回池前需要把 s[:cap(s)] 清掉。另外置零是 O(cap) 不是 O(len)，池子膨胀后成本会悄悄放大。

结论：这条我全收，但建议再往前一步——别依赖 MySQL 的隐式行为，把「是否真变更」做成代码里的显式 diff，顺手把 last_active 这类高频写从 users 表挪出去。

ON UPDATE CURRENT_TIMESTAMP 的语义是「行没实际变化就不动」，逻辑上能用，但它依赖的东西有点多：explicit_defaults_for_timestamp 的取值、驱动是否显式给该列赋值、binlog 格式，排查时得连 MySQL 版本一起猜。不如写入前先比一次：把进缓存的字段拎成一个白名单数组，array_diff_assoc(pick($new,$fields), pick($old,$fields)) 非空才 cache_ver+1。判断在代码里看得见，出问题一眼定位，也不用管时钟精度。

last_active 那类每请求 UPDATE 的列，光靠「不算进 diff」还不够——它照样让 users 行频繁变脏、redo 和 binlog 都在涨。两个做法：session 里记个 last_write_ts，超过 5 分钟才落库；或者干脆单开一张 user_activity 表，跟资料彻底解耦，一个页面刷 20 个用户也牵连不到 cache_ver。

「从库先行」补个风险：从库单独加索引会造成表结构漂移，之后主库同表 DDL 复制下来容易撞，验证完记得对齐或 drop；而且真上 pt-osc / gh-ost 时，从库上手工建的结构会被工具覆盖，建议只在临时同结构小表或影子库上试探。log_throttle_queries_not_using_indexes 那条确认，它只在 log_queries_not_using_indexes=1 时才生效，两个开关是一对，别只开一个。

最后一个小坑：cache_ver 自增记得带 WHERE id=?，别写成不带条件的整表 +1，那样一秒钟就把表锁住了。

@layer 这条比 :where() 更值得推，但有个前提容易被忽略：只有全站样式都进了层，层序才有意义——未分层的样式永远压过所有分层样式。

也就是说，如果只把 :has() 那几行包进 @layer overrides，剩下的老样式还在层外，那这块恰好变成全站最弱势的一份，越改越乱。真要迁就一口气分层，或者至少把存量样式整块塞进第一个层，新写的按 base / components / overrides 往下排。另外注意 !important 在层里是反的：靠前的层赢，且分层内的 important 反过来压未分层的 important，跟常规顺序完全相反，混用前先确认这条。

[id="b"] 那招注意是精确字符串匹配，id 带特殊字符或运行时被改过就漏；更土但更稳的替代是给元素补一个语义类，has() 只认类，可读性也回来了。

性能那条说到点子上。除了 Styles 面板悬停看 specificity，Performance 面板里打开 Selector Stats（需要在设置里勾一下）能看到每条选择器的匹配次数与耗时，:has() 挂在 body 上引发的重算会直接变成数字，比猜权重靠谱。另外 :has() 现在 querySelector 也能用，写几行脚本直接验证命中集合，比在 DevTools 里翻 DOM 快。

一句话收个纪律：参数只用类名、挂载点尽量往下压、别和 ID 混写。