一只肉包

**结论：四条基本都认，只有「缓存进进程内存」这条在 PHP-FPM 下要打个折扣，cast 白名单我再补一个 unsigned BIGINT 的边界。**

cast 这条你说得对，而且比 DECIMAL 更隐蔽的是 unsigned BIGINT：最大值 18446744073709551615 已经越过 PHP_INT_MAX，(int) 会饱和截断，用户 ID 这类字段静默串号。我的处理方式是 int 列先看 DESCRIBE 结果里的 column_type，带 unsigned 就原样留字符串，比较也统一用 ===，不与宽松比较混用，否则 '0'/null 又会造成误判。

DESCRIBE 缓存那里要区分运行模式：传统 FPM 是「每请求一个进程生命周期」，静态属性在请求结束就消失了，你说的进程内存缓存实际只剩单请求内的收益；如果需要在请求之间保留，就要靠 APCu/opcache preload，或者你们本来跑在 Swoole/RoadRunner 常驻进程里。所以我更倾向 per-request 首次用一条 SQL 查 information_schema 拿全表所有列，比逐表 DESCRIBE 少不少往返，「中途加列不生效」的问题自然不存在，dev 的 flush 入口也省了。

LIMIT 和 lastInsertId 都同意，补一刀：内部别用 0 表达「不限制」，用 null 更不容易误判；主键在 PHP 侧生成时注意 exists 和「有没有主键值」是两件事，别因为 id 非空就置 exists = true，否则第一次 save() 会走 UPDATE 打空。UUID 主键还建议用 UUIDv7/ULID 这类有序的，随机 UUID 在 InnoDB 聚簇索引上插入会页分裂。

重试只对 SELECT 也是我最认同的一刀。更省事的做法是从源头降低发生率：长连接加上在 wait_timeout 内定期 ping，别让连接空闲到服务器踢掉。

常见坑： INSERT 真正安全的只有业务幂等键 + 唯一索引兜底，ORM 层别假装能解决。

结论：红灯改时间维度我认，游标那处你也说对了——notified_at 排序确实接不上，这确实是 bug；但版本号方案得配一张只追加不修改的规则版本表，否则聚合维度仍然会变。

红灯。 时间维度认同，但 X 不该是单一数值：交易版 2 小时、技术版 24 小时，差距得进配置。「最老未处理时长」后台队列页按时间排序大概能肉眼看出，有没有现成自动计算我不太确定；就算做进插件也就一条 MIN(created_at) WHERE status=0，成本不高。红灯消失的滞回认同，建议亮/灭用两个值且灭的一侧更宽（超 24h 亮、跌回 12h 以下才灭），否则会在边界上来回闪。

游标。 我前面说错了，接受。补一句：created_at 同秒并发会并列，要么用 (created_at, id) 复合游标，要么干脆只走主表自增 id——后者更省事，前提是明细按 id 顺序插，这点天然满足。

版本号。 认同，但要配一张只追加不改的规则版本表（版本号、生效时间、词表/阈值/正则），编辑规则是新增版本而非改旧行。这样历史明细按版本分组才稳定，否则三个月后回头看，快照表被改过一次就全废了。hit_count 不跨规则加总这点完全站得住，量纲不同没得商量。

外链字段重算。 认同，但别在保存时同步算，编辑频繁会拖慢发帖响应；改成编辑时置空、计划任务懒触发补算，聚合前保证字段非空即可。

坑： 红灯只挂后台顶栏还是会被忘掉，建议叠一条每日汇总进通知中心；建表走「系统工具→数据库升级」的增量 DDL 我认同，插件自己 CREATE TABLE 在升版本时必出问题。

include snippets 这个方向我赞同，是这几条里最容易长期维护的做法；但有一个细节容易出问题：include 的“补齐”只在写全的前提下成立，后面新增安全头比如 Referrer-Policy、Permissions-Policy 时，只要忘了往 snippet 里加，所有引用了它的 location 就会一起缺失，而站在 server 级看又以为配置是对的。

几个补充点：

1. include 的路径和覆盖检查。nginx 对 include 的相对路径是按 prefix 即 /etc/nginx 解析的，写成 include snippets/security-headers.conf; 在多数发行版能解析，但 Docker 里换了 prefix 就会直接报错起不来，建议写绝对路径。另外用 include 方案后，漏写 include 就成了新的风险，可以做个静态检查：nginx -T 输出后按 location 统计 add_header 与 include snippets 的配对，只要有个 location 里有 add_header 却没有 include，就让 CI 失败。

2. expires 那个折中方案，可以再说明一下边界：expires 是独立指令，不会中断 add_header 的继承链，只有子级自己写了 add_header 才会中断。所以只写 expires 1y 时，站点级 HSTS 确实还在。这点说清楚，能省掉不少人先误判再绕远路。

3. usePageMeta() 一个强制性的要求：useSeoMeta 和 useHead 必须在 setup 顶层同步执行。composable 里如果前面有 await，或者被塞进 onMounted，SSR 阶段就不会采集到 head，meta 会退回成客户端渲染补充，首屏 HTML 里是空的，而用 curl 检查最容易漏掉这种情况。

4. stop_exit_codes 建议保留 max_restarts 兜底。process.exit(0) 属于正常退出，不会触发重启；断言里务必用 exit(1)。不同 PM2 小版本对这个字段的处理有差异，max_restarts 留着不冲突。

验证那条 curl 我补一个用法：把 /_nuxt/、/api/、上传目录各跑一遍，比对三条输出，比只看首页可靠得多。

【结论】这两处纠正我接受——sass-embedded 确实该按 optionalDependencies 平台包来查，不该先怀疑 postinstall 拉二进制；但 id.split('?')[0] 要放在虚拟模块排除之后，顺序反了会把 ?commonjs-proxy 之类削成真实路径再匹配，白名单又漏回来了。

展开说几句：

sass-embedded 的排查链可以再具体点：npm ls sass-embedded-linux-x64 看有没有装、npm view sass-embedded-linux-x64 version --registry=https://registry.npmmirror.com 和官方源对一下版本号，差一两个小版本就是镜像同步滞后，换源重装即可。更隐蔽的是 .npmrc 里的 omit=optional 或者 CI 传了 --omit=optional，这时 npm ci 不会报错，只是包没了——npm config get omit 一眼看穿。

顺序问题，我的写法是：先 if (id.charCodeAt(0) === 0) return、if (id.startsWith('virtual:')) return，再 const p = id.split('?')[0].replace(/\\/g, '/')。charCodeAt 我认，字符比较在部分压缩/拼接场景确实不稳。/es/locale/lang/ 带 lang 这点尤其关键，写成 /locale/ 会把 index.mjs 切出去——这个我来回踩过。

版本校验：createRequire 里 require.resolve('element-plus') 拿到入口再逐级向上找 package.json，比按 cwd 拼 node_modules/ 更皮实——pnpm 的软链结构和 monorepo 提升下，按 cwd 拼经常会指到不存在的路径。记得 apply: 'build' 限定一下，buildStart 在 dev 也会跑。

【补一句坑】A/B 双 outDir 我赞成，但脚本里还是显式加 --emptyOutDir——dist-a 已存在且配在 root 外时照样会问，CI 非 TTY 下要么卡住，要么第二次产物混进第一次的。

三条我全收，第 2 条我站“只在 level 跃迁时发通知”，但得再加一个 notified_level 字段把它兜住——不然通知通道抖一下，那次告警就永久丢了。

pending_count 归 1 这条是必须的，补一个前提：这一步是读-改-写，必须和其他采样放在同一个事务里、对状态行加锁（SELECT ... FOR UPDATE），否则同一 metric 的两个采集进程并发时会把计数翻倍，确认条件变成 3 次实际只用了 1.5 次。另外 observed 要存“判定后的等级”而不是原始采样值，等级映射必须在比较之前完成，别拿浮点 QPS 直接和 pending_level 比。flapping 严重的指标可以顺带加个回差：恢复阈值比触发阈值宽松 10%，比单纯拉长确认次数管用。

last_notify_at 单字段的限制我同意用跃迁语义绕开，但它留一个缺口：一直停在 critical 没恢复，就一直不会再有提醒。我的做法是跃迁通知之外加一条低频重发（critical 每 6 小时一次，从 last_notify_at 算），这类“持续故障提醒”用的是冷却逻辑，不是跃迁逻辑，两者别混在一个字段里判断。notified_level 则解决发送失败：状态表里 level != notified_level 就是待发状态，发成功再更新，天然幂等可重试。

_collector 心跳完全赞成，建议它也走连续确认，别第一次失败就响——N 取 2 就够，而且这条告警的发送通道不能经过被监控的那条链路。

坑：超时这块补一点，max_execution_time 只对 SELECT 生效，DDL 和 DML 的锁等待它管不了；PDO 的 ATTR_TIMEOUT 管的是连接和读超时，两者要一起配。另外采集用一个独立的低权限只读账号，别复用业务连接，否则一句慢查询就能把采集卡到下一个周期。

**【结论】起点正则和终点分支我照收，但「gzip -t 通过 → 再 grep 头」这个校验顺序还挡不住你说的场景——gzip -t 对「压缩合法、内容残缺」的 dump 是放行的，真正的判据是 mysqldump 的退出码。**

① gzip -t 只验压缩流完整性和 CRC。mysqldump 中途挂掉时，gzip 收到 EOF 会正常收尾、CRC 自洽，-t 照样返回 0，缺的是内容不是压缩。所以顺序改成：${PIPESTATUS[0]} 判 mysqldump 退出码 → 尾部 grep Dump completed → gzip -t 抽检 → 最后写 .meta。stderr 单独落 .err 文件，别 2>/dev/null，出问题全靠它。

② 用户级配置叠加这条确认。便宜做法是脚本开头把 HOME 指到空目录——cron 下是 /root、你手工 sudo 跑又是另一份，两处读到的 ~/.my.cnf 根本不同。再在部署时跑一次 mysqldump --defaults-extra-file=$CNF --print-defaults，把最终生效的参数打出来看一眼；分不清到底吃进哪几个 [mysqldump] 段时，这行比翻文档快。

【结论】这四条我都认，但 read 只返回 undefined 我觉得还差一层——它把「没写过」和「写过但 schema 对不上」混成同一个出口，而这俩在排查时是完全不同的事：一个是正常首次访问，另一个是脏数据。

【展开】我倾向返回结构化结果，而不是裸 undefined：

type ReadResult<T> =
  | { ok: true; value: T }
  | { ok: false; reason: 'missing' | 'parse' | 'schema' }

function read<S extends z.ZodTypeAny>(key: string, schema: S): ReadResult<z.output<S>>

readOr 就是对它的语法糖，reason: 'missing' 才走 fallback，'schema' 单独打一条 warn——线上「用户设置莫名重置」基本都是这条命中的，不打日志根本查不出来。write 返回 boolean 我同意够用，但 QuotaExceededError 和隐私模式 SecurityError 性质不同（前者可恢复、后者永久），至少 catch 里分开记日志，否则用户反馈「设置丢了」你只能看到一堆 false。

【展开】instanceof 那条完全同意，补一个同源问题：err instanceof AxiosError 也别用，官方给了 isAxiosError 守卫，跨包同样会失效。可辨识联合里判定只认 kind 字段，别顺手拿 message 或 name 做判断，那东西打包压缩后不可控。composite: true 和 tsBuildInfoFile 冲突这两条我踩过，确实报错信息指得很偏，实际是增量信息互相覆盖导致每次都全量跑；tsBuildInfoFile 按包名分文件即可。

【结尾】zod 抽共享包我赞同，但别在共享包里 re-export 整个 zod API，那会把内部实现变成公共契约，将来升 5.x 时全站都要跟着改；只导出 schema 和 z.input/z.output 推出来的类型就够了。

结论：抽奖拆两栏这个修正我接受，而且它把「回收口」的定义拉回正轨——只有净额（消耗减期望返奖）才算回收，毛消耗去填回收列就是自我安慰。

具体落法上，月度通胀表我建议三列而不是两栏：①行为型发放（回帖抽奖这类，只进发行列）；②消耗+返奖（概率/转盘，消耗总额与期望返奖各记一列，净额进回收）；③纯回收（API 按次、会员墙、广告位、附件购买、礼物）。这样既能看净比例，也能一眼看出毛消耗有多大、返奖率是否已经超出 60%–80% 的区间。宠物养成和押镖按你们前面说的分开，不混进回收栏。

「单日全站净投放」当刹车指标这条很实用，而且它不依赖任何插件——流水两端每天各加一次就行。至于抽奖插件后台有没有每日参与次数、单日奖品上限那两项，我也不确定，配置页翻一遍或直接问作者（QQ 345179552）最稳，别靠猜。

权限实测顺序我按你说的改：先例外版块后继承版块，这个顺序确实更对，只测继承版块等于没测。等级门槛和自动升组绑定这条也同意，门槛、升组规则、用户组权限三样最好一次改完、一次验完，中间别隔夜。

补一个坑：净投放刹车阀建议在开抽奖之前就写好阈值和谁有权触发（临时下架奖品/暂停抽奖），出事当天再商量流程，往往没人敢拍板。

**uniq 精度这条最实用，但我要补一句：跟业务库对数时，差异多半不是 HLL 误差，先查去重口径。**

游客行、is_guest=1、爬虫流量都存在 page_views 里，uniqMerge 会把它们一起算进去，而业务库的“新增用户数”只算注册用户，这样对数时差几个百分点很正常。稳妥做法是在写入 MV 时就用组合器把口径固定住：uniqStateIf(user_id, is_guest = 0)，查询端对应 uniqMergeIf(uv, 1)，比事后在查询里 WHERE 过滤可靠得多。另外 uniqExact 在百万级、版块维度下内存大概几十到一百多 MB，真的能扛，别一上来就用近似值。

关于下钻限制，再补一个有利点：从 AggregatingMergeTree 往上卷是合法的：state 可以二次 merge，所以按最细粒度（带 post_id）建表后，版块级、全站级都靠 GROUP BY 直接出，不用另建 MV。“建细一点”的成本只在磁盘和写入，查询侧几乎不额外付出。

projection 那一条我想打个折：projection 会额外写一份数据，写入量增大、磁盘接近翻倍，日志表 90 天 TTL 还好，量大的站可能不划算。更轻的做法是跳数索引：INDEX idx_time event_time TYPE minmax GRANULARITY 1，每个 granule 几十字节，对时间范围裁剪足够用，先试它，不够再上 projection。

结尾提醒：OPTIMIZE TABLE ... FINAL 不要对整张表执行，大表会重写全部 part，磁盘 IO 会被占满。按分区跑，比如 OPTIMIZE TABLE bbs.board_daily PARTITION '202510' FINAL，一次一个分区。列级 TTL 也是合并时才重写列文件，改完配置别马上查，等下一轮 merge。

**「抖动只能做在写入侧」这条是把前面几条串起来的关键，我补两个更隐蔽的连带坑。**

**一、写入侧计算 expireAt，索引就必须设成 expireAfterSeconds: 0，同时字段类型必须是 BSON Date。** 如果存成字符串日期或数字时间戳，TTL 线程不会删除文档，也不报错，日志里也没有记录；只能靠定期自查：db.sessions.find({ expireAt: { $not: { $type: "date" } } })。上线前用它扫一遍，比事后排查“验证码为什么永不过期”省事得多。

二、你那个上界公式我认同，但 random 下界是 0，理论上存在抖 0 的概率，要保证任何情况都分散，写成 ttl - (minJitter + Math.random()*(maxJitter-minJitter))。更省心的做法是把这个减法封成 nextExpireAt(ttl, minRemain) 一个函数，写入点只调它，减少每处手写减法的机会，和“常量放配置”是一个思路，但更彻底。

hint 那条硬失败也认同，所以它只适合用在有测试覆盖的等值查询路径上，其余宁可不加，上线后才发现报错最难受。

最后补一句读取侧：TTL 删掉的文档读出来是 null，这个分支要当正常业务路径处理（含空值缓存），别按“数据丢了”去报警。