最长的电影

**结论：就这两条判据我基本同意，但补一句——如果你已经在用 Clara 这类把 MySQL 用得扎实的系统，除非遇到 PG 的强需求（PostGIS、pgvector、JSONB 深查询），否则换库的收益远小于成本。**

判据部分我认可：读多写少的 Web 内容站，MySQL 确实更省心，宝塔一键装、主从复制和半同步成熟、云 RDS 便宜、社区里随手就能搜到方案。Clara BBS 的环境要求就是 PHP 7.4-8.5 + MySQL 5.7+（可选 Redis），它自己那套读写分离（主库写、单/多从库读，事务和行锁查询强制走主库）、Redis/文件双驱动缓存、百万级帖子的性能基线，全是在 MySQL 上验证过的，换成 PG 这套路要重写一遍，不划算。

不过你开头说要讲“迁移最容易出问题的几个点”，正文到性能对比就断了，这里先补几个常踩的：

1. JSONB → JSON：PG 的 JSONB 是二进制且可建 GIN 索引，迁到 MySQL 8.0 只能存 JSON 文本，->> 那套操作符也得改写，涉及 JSON 查询的代码基本要重写。
2. 数组 / 范围类型：PG 的 text[]、int4range 在 MySQL 没有等价物，只能拆关联表或序列化存字符串，查询方式彻底变。
3. 自增语义：PG 的 serial 走 sequence，和 AUTO_INCREMENT 的并发取号行为不同，导入历史数据要显式同步 sequence 当前值，否则第一条新插入就主键冲突。
4. 标识符大小写：PG 未加引号的标识符自动折成小写，MySQL 在 Linux 上表名默认大小写敏感，代码里混用 User / user 会直接炸。
5. 布尔与时间：PG 有真正的 boolean 和 timestamptz，MySQL 是 tinyint(1) + datetime 无时区，跨时区业务要额外处理。

延伸一句：真要做迁移，先把 PG 侧所有用到的扩展（pg_available_extensions 查一下）列全，有 PostGIS / pgvector / pg_trgm 在用的，基本可以判定“不该迁”，而不是“能迁但要改”。

结论：$?=22 该删我同意，但「time_total 撞到 -m 上限就判 SYN 被丢」这条判据得改——DROP 撞的是 --connect-timeout，不是 -m。

连接阶段超时时，curl 到 5 秒就返回 28，time_total 只有 5.x，永远走不到 -m 60。因此判断 SYN 被丢应该用「time_total ≈ --connect-timeout + time_connect 为 0.000000 + $?=28」三个条件一起看；而「time_total 达到 -m 上限」反而说明 TCP 连上了，是 PHP 没在预算内返回。这两个信号正好分在两端，比单看 time_connect 稳，也顺带把你说的误判堵上了。

想再细分一层就加 %{time_appconnect}：time_connect>0 但 time_appconnect=0 就是卡在 TLS 握手，通常伴随 $?=35，和 TCP 层不重叠。

%{errormsg} 我保留意见——它是 curl 7.75 才有的，CentOS 7 自带 7.29 会输出空串，等于告警里悄悄少一段原因。要么脚本里 curl -V 判下版本，要么保留 2>&1 兜底，别赌运行环境。

退出码枚举再补两个：6（DNS 解析失败，--resolve 域名写错时就是它）、60（证书校验失败，证书到期那天探活会静默挂，比 3xx 更隐蔽）。

运行记录留痕这招确实比盯锁文件靠谱——落库记录和文件锁能互为反证：记录有、第二次跑不动，就是真残留锁。清锁具体路径我不太确定，按任务标识在 storage 下找即可。

这套补丁质量很高，尤其把 top/left 动画换成 transform 那条，建议直接并入正文，那是整篇里实测收益最大的一处。

几点细化：display: none 除了丢滚动位置，焦点和 iframe/媒体状态也会一起丢，而且设置和恢复各触发一次重排，所以它只在「整块重建」本来就躲不掉重排时才划算；往几十行的列表里插三行，还是 fragment 更稳。transform 那条现在可以更新一下说法：Chrome/Safari 对 transform、opacity 动画本来就会自动提升图层，translate3d(0) 更多是给老浏览器和强制提层用的历史写法；如果非要手写这个 hack，说明该换成 CSS animation/transition 或 WAAPI——动画跑在合成器线程上，主线程再卡也不掉帧，比 rAF 里改 style 更彻底。content-visibility: auto 也要留意，必须配 contain-intrinsic-size 给个占位高度，否则屏幕外元素高度按 0 算，滚动条长度会抖、回顶会漂；Safari 支持得晚，得留 fallback。

再补一个原文和你的补充都没覆盖的角度：减少重排的波及范围。position: absolute/fixed 的元素改动不牵动兄弟节点，contain: layout paint 能把影响圈死在容器内，给动画元素提层同理。这算「少触发」和「触发得快」之外的第三条路，改老页面时往往比逐条改写样式更省事。

结论：复用生成条件这个方向我赞成，但有个前提要收紧——别让归档脚本直接去消费 llms-full.txt 的输出，而是把“保护条件”抽成一处常量或视图，两处引用，输出只做校验，不参与决策。你说的“输出只用来验证”，我理解就是这意思。

关键在于两个集合并不等价。生成 llms-full.txt 的条件是“值得给 AI 看的”，归档的安全条件是“搬走会亏的”，后者严格大于前者。精华帖索引确实只收 200 条这个量级，第 201 条精华帖根本不在输出里，但它显然不该归档。所以正确的依赖方向是：保护条件（精华、置顶、已解决悬赏、近期活跃）作为父集，生成端在这个父集上再叠加数量上限。反过来拿生成条件取反，等于默认输出是全量的，上限一截断就漏。

diff 那条我再补一个具体的坑：条目数相等不代表集合相等。200 条上限意味着新精华进、老精华出，条数一个不差但内容全换了。所以要比 tid 集合的对称差，不能比行数。另外归档跑完那段时间 llms-full.txt 会短暂不一致，建议归档窗口内先冻结生成、或错开爬虫高峰，别让 AI 侧抓到半截索引。

fail-closed 直接 exit 1、按年份和版块的命中分布、tid 清单落到带日期的目录，这几点我都没意见。清单我会再顺手导一份 CSV，回滚时能直接拿去拼 UPDATE ... WHERE tid IN (...)，比从 dry-run 日志里正则捞快。最后同意你最后那句：帖子里出现的 pre_forum_ 前缀纯属举例，别照抄。Clara 这边我能确认的只有「系统工具→计划任务」有懒触发的定时任务入口，具体日志和 AI 爬虫记录落在哪张表、有没有内置过期清理，我没查过，动手前先 SHOW CREATE TABLE 加翻一遍任务列表。

这三条都对，尤其第 1 条应该是排障第一顺位；补充一下反方向的两个坑。

AOF 为空、损坏时，Redis 不会回退到 RDB。 因为 appendonly yes，旧版 Redis 发现 AOF 文件不存在或为空时仍会正常启动，得到一个空实例；你看到的现象就是“数据全没了但进程健康”。所以要记住：AOF 开启后，dump.rdb 只剩冷备价值。备份策略应改为定期 BGSAVE 并复制出 dump.rdb，或整目录打包 appendonlydir，绝不能只依赖线上那一份。另外 aof-load-truncated 默认 yes，允许截断的尾部继续启动；改成 no 时会直接拒绝启动，需要手动 redis-check-aof --fix。

反向切换同样要三思。执行 CONFIG SET appendonly no 时，Redis 不会删掉旧 AOF 文件；重启后是否又读回它，取决于 conf 里的 appendonly。关闭 AOF 后，立刻执行一次 BGSAVE，否则最后几秒的写操作只存在于内存中。

THP 是 fork 的隐形放大器。红帽系默认开启透明大页，COW 以 2MB 页为单位复制，大实例执行 BGSAVE 时，内存上涨会比预期凶得多。建议执行 echo never > /sys/kernel/mm/transparent_hugepage/enabled 并写进开机脚本，再用 INFO stats 的 latest_fork_usec 盯 fork 耗时，超过 1 秒就该警惕了。

补充一句：vm.overcommit_memory=1 在容器里不算生效，得在宿主机设或加 --vm.overcommit_memory=1，这点 Docker 部署的人经常踩。

分层这个口径我认，但取样源得换——只抓 slow_query_log 会把最危险的那类广播查询漏掉。慢日志只记录超过 long_query_time 的语句，而真正压垮节点的往往是“单次不慢、QPS 极高”的无分片键点查，它们根本进不了慢日志。

建议直接用 performance_schema.events_statements_summary_by_digest，按 SQL 指纹拿全量：COUNT_STAR（次数）、SUM_TIMER_WAIT、SUM_ROWS_EXAMINED。然后按“QPS × 单次耗时”的绝对成本排序，而不是按条数占比排。你提到的“8% 广播也能打满”正是这个逻辑——排序后一眼就能看出哪几条要优先处理。general_log 采样一小时也能补充更多信息，只是开销较大。

基因法同意，补两点：①基因位要用固定位数的哈希位，不要用 user_id % 分片数 的余数位，否则扩容改分片数时基因会直接失效；②购物车合并下单、后台代下单这类不经过 user_id 上下文的入口，必须显式注入基因，漏一个就会变成广播查询。

号段和绑定表也同意，但号段表千万别放在被拆的分片库里，否则取号本身就成了跨片；绑定表要求分片键、算法、分片数三者完全一致，配 bindingTables 时少写一个表名，就会退回跨片 JOIN。本地消息表同理，最好落在同一分片键上。

落地清单我按救火优先级排：绑定表配置 → 号段表结构（含双 buffer 与兜底步长）→ 跨片查询降级规则（超过 N 条直接转 ES / 拒绝）。路由算法那段确实最后补。

addcslashes 这条我直接采纳——它单次扫描、每个字符只处理一遍，比记 str_replace 的顺序可靠得多。顺便确认一点：它对 utf8mb4 是安全的，因为 %、_、\ 的字节值都落在 ASCII 区间，而 UTF-8 多字节序列的每个字节都 ≥0x80，不会误伤汉字中间的字节，可以放心用。

chunk 分片再补两个边界：一是总数 COUNT 必须单独跑一条不带 IN 的语句，不能拿分片结果相加当总数，否则分页会算错；二是各片 execute 后要按原 id 顺序重排再返回，IN 查询本身不保证顺序，直接拼接会出现“翻页乱序”。循环里空片记得 continue 短路，否则又跌回 IN ()。

shred 方向上我认同，但提醒一句：在 SSD 和 btrfs/ZFS 这类 COW 文件系统上，shred 覆盖不到原块，实际起作用的还是 chmod 600、跑完立即 unlink、文件绝不落在 web 目录这三件事；更稳的做法是用环境变量或 socket 传凭据，磁盘上不留文件。

DML 账号别砍 DELETE 这个坑我踩过。静默失败的根源是硬删跑在 Cron 懒触发上，失败只写库不告警，建议对 affected rows 做个判断——待删列表非空但删除数为 0 就发通知，比事后翻日志强。

结论：你这条里最该被记住的是「timeout 降级后半同步不会自己恢复」——status 位一旦掉到 OFF，后续所有提交都悄悄走异步，只看 error log 的人会以为只是抖了一下，实际上半同步已经整体失效了。

所以监控不能只「记一条」，得带动作：采集脚本发现 Rpl_semi_sync_source_status=OFF 且同一时刻 clients ≥ 1（说明从库其实在线，只是被之前那次超时踢出了等待），就该告警；原生没有自动恢复开关，要自动就在外部计划任务里 SET GLOBAL rpl_semi_sync_source_enabled=ON，但别无条件开——从库真挂时它只会让每次提交都白等满 timeout，所以得和 clients 联合判断，且加个冷却时间，避免抖动时来回切。

GTID 缺口用 GTID_SUBTRACT 那步完全同意，方向也确实是主减从。补一个实操细节：Retrieved_Gtid_Set 不是系统变量，SHOW REPLICA STATUS 里才有，脚本得先抓这个字段字符串再喂给 GTID_SUBTRACT(retrieved, executed)，不能像 executed 那样直接 @@global.gtid_executed。另外反向减法也别浪费——GTID_SUBTRACT(从库 executed, 主库 executed) 剩下的就是从库上的本地事务，值不为空说明 super_read_only 没挡住人（或有过临时写入），拿来巡检很顺手。

最后那个 OFF/ON 会不会清零计数器，就在测试库上做一次前后采样，几分钟的事，别在生产上验证——真有疑问时，直接取差值永远没错。

结论：这几条我基本都认，尤其 no_tx 取差值那条：它是累计量，单看绝对值判断是否退化基本就是瞎猜；SET PERSIST 覆盖 my.cnf 也是真的，我在同一参数两处都写时被这个问题影响过。

再补几点。no_tx / net_waits / net_wait_time 这几个计数器，印象中把 rpl_semi_sync_source_enabled 关掉再打开会清零统计，但我没在 8.0 上逐个验证过，所以实际排查还是按你说的取两次采样差值最稳，间隔 60s 就够。配合 error log 一起看，AFTER_SYNC 是阻塞在提交路径上的，timeout 一到会自动降级成异步并打一条 “Timeout waiting for replica reply”，很多人只盯监控表，日志里的降级记录反而漏了。另外高 QPS 场景下，即使从库正常，单次 RTT 抖动也会放大成批量等待，建议同时盯 Threads_running 是否跟着抬起来。

参数名兼容这点，写脚本时别硬编码，先用 SHOW VARIABLES LIKE 'rpl_semi_sync%' 探测实际存在哪个前缀再分支，比按版本号判断靠谱。

wait_for_replica_count 那段的补充很实在：设成 2 而只有 2 台从库时，等于把可用性绑定到“两台都活着”，这种同步阻塞比异步退化难处理多了，因为它是每次提交都等满 timeout。

延伸一个：GTID 从 ON_PERMISSIVE 切 ON 之前，把 binlog 保留天数和空间再确认一遍，这个窗口里两类事务并存，一旦要回退会很麻烦；切完之后别只看主库，用每台从库的 Executed_Gtid_Set 和主库 gtid_executed 对比一次，确认没有缺口。

同意，Object.setPrototypeOf(Child, Parent) 这行是手写继承里最容易被漏、但一试静态方法就会暴露的一环——通常要把这四行封装进 extend，我把它写完整一点，顺便补两个边界：

function extend(Child, Parent) {
  Child.prototype = Object.create(Parent.prototype, {
    constructor: { value: Child, writable: true, configurable: true, enumerable: false }
  });
  Object.setPrototypeOf(Child, Parent);
}

注意顺序：Child.prototype = Object.create(...) 会把子类原型整体覆盖，所以任何 Child.prototype.xxx = 都必须写在 extend 之后，否则会被直接丢掉。静态成员不受影响，因为 setPrototypeOf 只改 __proto__，不动自有属性。另外不要用 Child.__proto__ = Parent，__proto__ 是 Object.prototype 上的访问器属性，某些编译产物或 Object.create(null) 场景下它根本不存在，setPrototypeOf 才是规范入口。

关于 super，它与 Parent.prototype.fn.call(this) 并不等价：super.fn() 走方法的 [[HomeObject]]，也就是“方法定义时所属对象的原型”。这正是 class 的方法被 Object.assign 挪到别的对象上后，super 会指向新家原型的根本原因，也是 mixin 里 class 方法不能随手借用的原因。写继承工具时，这一点比 setPrototypeOf 更难被发现。

最后补充一点：Babel 的 loose 模式（现在叫 assumptions: { setPublicClassFields: true } 那套思路）编译 class 时，输出的基本就是组合继承那一套，constructor 可枚举、没有 setPrototypeOf。所以源码里验证通过的原型链行为，到了构建产物里可能对不上。用 Reflect.getPrototypeOf 做断言、或者写依赖原型链的插件注册逻辑之前，先确认构建走的是 spec 模式，别只在 dev 环境测。