wbcm

三条都成立，但第一条的修法得再往下想一层——WeakSet 只对原始对象生效，不能在「包装后再打标」的顺序里用，否则永远命中不了。

关于非 Error 对象：正确做法是把打标和归一化分成两个阶段，打标是「尽力而为」的前置步骤，只对 typeof err === 'object' && err !== null 生效；然后无论打没打上标，都统一归一化成内部结构 { kind, message, stack } 再进 Map 合并。关键是两条路径产出同一种 report 结构，下游不关心它是对象还是字符串。如果反过来先包装成对象再 add 进 WeakSet，每次都是新引用，等于白打。

关于 Map 上限：200 条这个数没问题，但淘汰策略建议不要「丢最旧」。firstAt 最早的那条往往是持续爆发的老错误，淘汰它反而欠采样；按「最久未被命中（LRU）」或「count 最低」淘汰更合理。另外强制 flush 要防递归：flush 本身失败又入队会立刻再次超限，建议加 flushing 标志，期间新错误进 overflow 缓冲，超了就直接丢弃并记 dropped++，上报时带上这个计数用来校准丢失率——否则你会以为错误变少了。

关于构建 hash 归一化：完全同意，补一点——归一化规则别写死正则。/assets/\w+-[a-f0-9]{8}\.js/ 只适合 Vite 默认输出，换 webpack 或用了 [contenthash:6] 就失效。建议初始化时传入一个 chunk 名映射表或用 /(?:[.-])[a-f0-9]{6,10}(?=\.(?:js|css))/ 这种更宽的规则。node_modules 帧的问题：monorepo 里 link 的自家包也在 node_modules 下，一律剔除会丢关键帧，折中是只剔除非 workspace 路径。CDN 前缀同理，用初始化时注册的域名白名单做归并，比猜主域名可靠。

self-disable 那条：加个前置判断，navigator.onLine === false 时不计失败次数，否则用户断网一次就把监控关了。

坑：打标层和合并层确实不能共用一个 try，最好连函数都分开，打标函数整个包 try 且不返回值。

结论：这套补充我基本全收，只有一个操作细节想简化——"清 cookie 再验证"不如直接开无痕窗口，分别从 www 和裸域两个入口各登一次，比对是否都被 301 归一到同一处，比手动清 cookie 更不容易漏。

CSRF 那条的区分点很实用：编辑器本身带自动拉新 token 重发一次，所以偶发一次能过、连着几次都过不去，才该怀疑域名/会话，别一冒这个提示就去动配置。

分表摸范围再补两类容易漏的：一是用户签名、公告、专题导读这类富文本字段；二是插件自建表——插件内容存在自己表里，主表 COUNT 根本统计不到，装过插件的站务必把插件表也过一遍。

抽样 → UPDATE → 再 COUNT 归零，这个收工标准我认同。补一点：序列化字段走"后台重新保存触发重写"，量大时手点不过来，可以先按旧域名 COUNT 出命中记录的 id 列表，只挑那几条重存，不用全量过一遍。

/answers.html 分两种口径我同意；"关闭"是否影响进问答池我不太确定，但进回收站肯定不在，稳妥就是两个口径各核一遍，别拿单一页面下结论。托管流水反查我觉得比翻帖子状态更准，注意区分：取消悬赏会退款、采纳会发放，所以真正要找的是"有冻结、既无发放也无退款"的记录。

最后：老域名别急着退，保留 301 至少一年——外站引用和搜索结果里的旧 URL 只能靠它兜。

三条我都认同，尤其第二条 removeRoute 是全篇最容易出线上事故的地方；我再补三个实现细节，都是踩过才想起来的。

一、守卫里的 fetchProfile 要做并发去重。 你提到的 routesReady 幂等能挡住重复 addRoute，但挡不住并发导航：页面刷新时如果同时有多个请求触发守卫（子路由重定向、组件内 router.push），fetchProfile 会被并发调多次，导致权限还没写入就进了路由判断。稳一点的做法是在 store 里缓存 promise：if (profilePromise) return profilePromise，拉完再清空，这样无论多少并发都只打一次接口。

二、v-permission 必须挂 mounted + updated 两个钩子。 只用 mounted 会有个隐蔽 bug：权限是异步拉的，首屏渲染时 permissions 还是空数组，按钮被 remove 掉后就算权限到了也不会回来。用 v-if 控制的场景更要注意——两者优先级打架，指令可能在元素还没插入 DOM 时就执行，el.parentNode 是 null 直接报错，记得加判空。

三、权限码共享不建议各写一份常量文件。 前后端各维护一份 PERMISSIONS 迟早对不上。实际做法是把枚举放一份 JSON 或 PHP/TS 同源定义里，前端用 Vite 的 import.meta.glob 或简单 codegen 生成，后端中间件引用同一份，改一处两边同步。

延伸一个坑：登出用 location.reload() 确实最稳，但要注意 token 清空要在 reload 之前完成；如果先 reload 后清 token，新页面会带着旧 token 重新拉一次 profile，表现为“退出了还能进”。

【结论】SAVEPOINT 那条我认，但收窄范围得再切细一格：**只有 1205 能靠 savepoint 收窄重试范围，1213 连「只重跑 savepoint 之后」都做不到。**

原因是死锁牺牲者被 InnoDB 整事务回滚后，事务本身已经没了，此时执行 ROLLBACK TO SAVEPOINT 会直接报 1305（SAVEPOINT does not exist）——正好被那层 catch (\Throwable) 吞掉，但关键是：即便吞掉，savepoint 之前那几笔写也已经没了，你只补后半段就是数据缺口。所以 1213 的路只有一条：整个事务体重跑，前提是事务体内没有外部副作用（发通知、调支付、写 Redis 计数这些必须挪到提交之后）。反过来 1205 在默认 OFF 下事务还活着，ROLLBACK TO SAVEPOINT 才是真正的「切小」，你说的路径对它完全成立。

hydrate() 旁路我完全同意，补两点：快照就用 $this->original = $this->attributes; 一把赋值（PHP 数组是值拷贝，不用怕引用），同时置 exists = true；另外它正好接上前面的「脏集为空提前返回」——部分列 select 出来 original 只有主键+选中列，没改动时脏集自然为空，直接 return，不用特判。

MYSQL_ATTR_INIT_COMMAND 我也认，但它是建连时执行一次，若开了 ATTR_PERSISTENT，连接是复用的，所以里面设的必须是绝对值，并且代码里禁止再 SET SESSION 改它，否则残留值会串到下一个请求。退避公式我加个上限：min(mt_rand(20,100) + 20*(n-1), 500)。

【坑在末尾】1213 那层 rollback 失败的日志要能区分「预期失效（1305）」和「真故障」，不然 1305 天天刷日志，真问题反倒被埋了。

【结论】同意，importStyle 和全量 CSS 只能留一个这点没毛病；再补一点——manualChunks 的对象写法和函数写法在 element-plus 这种带深层路径的包上行为不一样，值得顺手改掉。

对象形式 'element-plus': ['element-plus'] 是按入口模块的静态依赖图来收集的，而 es/components/*/style/css 这类由 resolver 补进来的深层路径不一定被收进去。结果就是你以为样式都收进 vendor 了，其实还散落在各个页面 chunk 里。改成函数形式更稳：

manualChunks(id) {
  if (id.includes('/node_modules/element-plus/')) return 'element-plus'
}

前后斜杠要带上，避免 element-plus-icons 这类包被误判进去。

重复引入别用肉眼检查，做个 A/B 对比更直接：同一份代码构建两版（importStyle: 'css' 与 false），用 gzip -c dist/assets/*.css | wc -c 把两个结果相减，差值就是重复量；顺便用 grep -c 'el-message' dist/assets/*.css 看命中几次，一眼就能确认。

sass 编译慢可以缓解一下：Vite 5.4+ 开启 css.preprocessorOptions.scss.api: 'modern-compiler' 并装 sass-embedded，冷启动和 HMR 会好转不少，比退回全量 CSS 划算。

【补一句坑】版本错配可以在 shared 里写 requiredVersion: '^2.8.0' 但先不开 strictVersion，改成在 CI 里比对一次基座与子应用的 lock 文件——strictVersion 一开，基座每次升级所有子应用都得跟着发版，小团队很容易被卡住。

两处我都收，instance_id 那条是这套设计里最容易被漏掉的，我建议直接把它做成 host:port/role 字符串而不是自增 ID。

理由是主从会切换、实例会重建，自增 ID 对不上历史数据，host:port 至少能人工对上号；同时把 role 一起写进去，图上才能一眼分出主从两条 QPS 曲线。配套的坑是：从库下线或角色变化后，旧那行会永远停在 critical 一直走低频重发，得有个 retired 标记或采集端主动把不再出现的 instance 置为 retired，否则告警噪音会盖过真实故障。

重发和跃迁两条更新路径我完全赞成。实现上建议把“待发”判定收敛成一个查询：level != notified_level OR last_notify_at < NOW() - 重发间隔，发送逻辑只有一处，成功后按来源分支更新字段，避免两处 UPDATE 写歪。NOW() 取库时间这点在 Clara 上正好安全——这条 UPDATE 是写操作，走主库；但反过来的读取判定要注意，状态表这种强一致读别让它走从库读到旧值，事务内或加行锁的读会强制走主库，正好符合需求。回差只给惯性指标、pending_count 封顶 10，我都同意，QPS 加回差确实会把突增吃掉。

降级出口是这套设计里唯一的真空白，你说得对。本地落盘建议追加写 + 按大小轮转，别用会阻塞的锁；恢复后补写带 status 标记，图上就能和“没采到”区分开。

坑：只读账号的权限清单别写漏——SELECT + REPLICATION CLIENT（SHOW SLAVE STATUS）+ PROCESS（看 Threads_running 明细），读慢日志还要 FILE，少一个就是静默返回空。另外主从切换后，新主上 SHOW SLAVE STATUS 返回空集是正常现象，采集端要把“空集”判成“非从库”而不是采集失败，不然切一次主就报一轮心跳丢失。

【结论】读写拆两个签名我照做，但 read 的失败路径没在签名里体现，以及错误归一用 instanceof 分类型，这两条不补，闭环只在 happy path 上成立。

【展开】read<S>(key, schema): z.output<S> 这个签名有个隐含前提——一定读得到。实际 localStorage.getItem 返回 null、JSON 解析失败、schema 不匹配三种情况都得有出口，返回 void 或直接抛都不是好选择。我一般拆成 read<S>(key, schema): z.output<S> | undefined 加一个 readOr<S>(key, schema, fallback: z.output<S>): z.output<S>，让调用点自己决定要不要兜底，而不是在封装层统一猜。write 也有同样问题：隐私模式/配额超限下 setItem 会抛 QuotaExceededError，返回 void 等于把失败静默吞掉，至少该返回 boolean 或让异常冒泡。

错误归一那条我补一个更隐蔽的：catch 里判 err instanceof HttpError 在 monorepo 里不可靠——两个子包各自装了一份依赖、或者打包后被复制成两份类定义，instanceof 直接失效，而且失败是静默的（永远走不到那个分支）。改用可辨识联合 { kind: 'http', status } | { kind: 'biz', code }，靠字段判定，跨包跨实例都稳。

references 那条你说的对，我再加一个前置条件：只写 references 不写 composite: true 是无效的，报错信息指向很偏；另外 tsBuildInfoFile 在 monorepo 里如果多个包落到同一路径，会互相覆盖增量信息，表现出来也是"莫名全量跑"。

【结尾】zod 锁小版本之外，建议把 schema 抽成内部共享包统一升级——z.string().email() 这类 API 在 4.x 有语义变动，各子包版本漂移时，同一份数据在不同模块校验结果不一致，排查成本极高。

结论：三条我都接，尤其“归属日取扣费日”这条：用批次号（biz_no）统一归组后，同一批扣费与返奖算一个整体，整批记在扣费日，跨零点问题就从统计层面解决了；不必给单笔流水打时间补丁，也不用为每天的归组方向争论。

不对称授权我同意，但要补一个落地细节：它得有权限点支撑，不能只靠流程约定：「暂停抽奖」单独授权给运营值班岗，「恢复」只留给管理员，且恢复时必须填复核人和理由，写入管理日志。小站凑不齐两人时，折中办法是恢复加 24 小时冷却，并在站务群公示，让第二人至少有拦的机会。

基线和下限两个修正比我原来的版本更靠谱。我的做法是：用品类近 30 天非活动中位数当基线，再加绝对下限（单日净投放超某个货币量才触发），两条同时满足才报警，节假日福利就不会天天响。例外标记位建议做成活动备案表的字段，勾选后自动从基线剔除，不靠人记。“连续 3 天为正”同样挂这个标记位。

冷启动那句我完全同意，新站为凑 60% 砍产出是本末倒置。

坑：批次号想立住，得同步维护一张原因码字典，记清每个 reason_code 对应哪个归类、是否计入回收、归属日规则。新插件上线（宠物、押镖、抽奖二期）必须先登记再启用，否则半年后导出表里全是孤儿原因码，三列还是失真。

结尾那段 INSERT ... SELECT 正好截断了，先补上，因为灌数据这块很多人卡的地方都在这里：

INSERT INTO bbs.page_views
SELECT
    today() - number % 90          AS event_date,
    now() - number * 30            AS event_time,
    number % 50000                 AS post_id,
    number % 60                    AS board_id,
    toUInt8(number % 5 = 0)        AS is_guest,
    number % 5000                  AS user_id,
    rand() % 120000                AS stay_ms
FROM numbers(5000000);

numbers(N) 是 ClickHouse 自带的一张虚拟表，一行代码就能造出千万级数据，做压测非常好用。上面这一条数据量大约 500 万行、每条 3 秒左右，足够做压测。

补几个实践中的点：

1. board_id 建议用 LowCardinality(UInt16)。版块数量就几十个，字典编码后压缩率和扫描都更好；同理帖子状态、用户组这类也用得上。基数超过几万的列不要硬套 LowCardinality，反而会变慢。

2. 千万别循环单行 INSERT。这是新手最容易踩的坑：每次 INSERT 都会在磁盘上生成一个 part，攒到几百个就触发 Too many parts 报错，写入直接卡住。要么用 INSERT ... SELECT 批量灌，要么在应用侧攒够 1 万到 10 万行再批量提交一次；官方的 clickhouse-client --query "INSERT ... FORMAT JSONEachRow" 配合 stdin 也行。

3. 排序键顺序有讲究。你写的 (board_id, event_date, post_id) 是对的——把查询中最常用的等值过滤列放最前面，才能让稀疏索引起作用；如果查询常按时间范围扫描，把 event_date 往前挪。只有带上排序键前缀的条件，才能真正裁剪数据、跳过大量数据块。

4. 预聚合用物化视图，不要每次都做全表扫描。“近 7 天新增用户趋势”这类固定报表，建一张 SummingMergeTree 加物化视图，写入时自动按天聚合，查询就从秒级变成毫秒级。论坛场景尤其推荐这么做。

回到论坛这个例子：把 MySQL 的业务数据同步一份到 ClickHouse，统计完全不用实时同步——每天凌晨用计划任务跑一次增量同步就够了。Clara 本身就有计划任务体系（Cron::register 注册，前台访问懒触发，也可以配 crontab 打 /cron 入口），加个插件每天把浏览和签到流水搬过去，比在 MySQL 上硬扛统计查询划算得多。

最后一个坑：TTL 和分区别一起设得太细。按月分区配 90 天 TTL 是合理的；如果按天分区再配 90 天 TTL，就会产生 90 个活跃分区，后台合并线程的压力会明显变大。

结论：这几条我全收，尤其「cancel/close 只清一遍」和「RO 超阈值还原成真报警」这两点——它们省掉的都是一类平时排查不出来的问题。

单值陷阱我再补一个：除了横向滚动容器，inline-size 由内容决定的都得写四值，比如 inline-flex 的子项、grid 的 auto 列、以及 white-space:nowrap 的标签条。我一般直接改用逻辑属性，分别写 contain-intrinsic-inline-size 和 contain-intrinsic-block-size 两条，比 auto 400px auto 400px 可读性好，也不容易漏写一轴。

body:has(dialog[open]) 有个好处，你可能没提：它是按「存不存在 open 的 dialog」判断的，多层弹窗天然不会提前解锁。两个注意点：一是 dialog 被动态插到某个带 overflow 的容器里时，锁的是那个容器，不是 body；二是 :has 在 Safari 15.4 / Chrome 105 以下不生效，老设备还是得用 JS 加 class 兜底。另外 ::backdrop 加过渡时，记得配合 @starting-style，否则打开那次是瞬跳。

焦点归还这块：close() 时浏览器多数会自动还给打开前的元素，但触发元素被重渲染或移除后就丢了，封装里存一份 activeElement 更稳。还有 dialog 里的 autofocus 是生效的，别和手动 focus 打架。新版 Chrome 有 dialog.requestClose()，能让 Esc 和按钮关走同一条路径，很香但支持面窄，别当基线。

will-change 摘除建议 transitionend 和 setTimeout 兜底两条都上——过渡被打断时 transitionend 不触发，图层就一直挂着。

最后自查：Layers 面板和 Rendering 面板的 Layer borders、Paint flashing 可以一起开着看，光看内存数字容易漏掉意外的合成层。