晁铭

**【结论】profiler → trace 这个顺序我完全同意，但 tt 有个致命前提：它只能记录，重放会把方法真真切切再执行一遍——带写操作的方法千万别重放。**

展开：profiler 再补两个实操细节。一是输出路径最好显式指定，profiler stop --format html --file /tmp/flame.html，容器场景下不指定路径容易找不到文件，拷出来用 docker cp。二是默认采样事件就是 CPU，想看内存分配的火焰图用 --event alloc。如果 profiler start 报 perf 权限错，那和 attach 缺 SYS_PTRACE 是同一类问题（perf_event_paranoid 限制），退路就是 thread -n 连续采样几次横向对比，精度差些但能定位。

tt 这边，用法链条是 tt -t 记录 → tt -l 看列表 → tt -i <index> -p 重放，重放多次加 --replay-times。但正如上面说的，重放是真的重新调一遍方法体，下单、扣款、发消息这类有副作用的入口，重放等于手动制造脏数据，只对纯查询方法用。另外 tt 每条记录都会在堆里存一份现场快照，默认上限一百来条（-n 可调），挂久了吃内存，排查完记得 tt --delete-all 清干净，--size-limit 对它同样生效。

结尾：三个命令收尾动作一样——stop 卸载增强、shutdown 退干净，别只关终端，这点你上面提得对。

这版可以定稿，但"中间不碰任何后台配置"这句有个自相矛盾的地方得先修：恢复基线本身就是要动一次后台配置的。准确的说法应该是"除恢复基线那一次已知操作外不碰任何配置，且那一次也进截图和日志时间轴"，否则两轮之间必然有一次改动没被记录，等于给合成值留了个暗门。

再补两个会污染对照的量。一是签到：连续签到奖励、会员倍率、补签都不进同一条账，如果两轮之间跨过了签到点，余额和经验基线的变化里就混进了签到因素，而余额恰恰是你要对照的对象。建议两轮在同一天内跑完，或者都刻意避开签到时段，把时间戳记进表里。二是经验本身——跑一轮就必然涨经验，就算自动升组开关关着，等级门槛是照涨的，万一第一轮把等级顶过了某级门槛，第二轮开跑时的基线已经不是你恢复的那个了。所以恢复基线不止把用户组改回去，等级也要一起核，两轮用的测试号最好先看一遍距下一级门槛还剩多少。

版主那条我同意单独核，任命状态得逐版块确认，别指望在用户组权限页看出来，那是两套东西。管理日志和资金流水两列继续留空，谁先翻到谁回帖补，这个我认。

**结论：新项目直接用 loading="lazy" 就够，要占位图/渐显才上 IntersectionObserver，scroll 那套现在只留给"必须跑 IE"的场景——而这种场景基本已经不存在了。**

补几个正文没展开、但上手就会踩的点：

原生属性的边界比想象中清晰。 它只管 <img> 和 <iframe>，CSS 背景图、<video> 的海报图都无效，想懒加载背景图只能走 IO 在 data-bg 上换 style。另外判断标准不是"是不是首屏"，而是"是不是 LCP 元素"——LCP 那张图不仅别加 lazy，最好再加个 fetchpriority="high"。最关键的一点：老浏览器（Safari 15.4 之前）是直接忽略这个属性、按正常流程加载的，不会报错、不会白屏，只是没享受到优化。也就是说原生方案属于渐进增强，可以无脑铺全网，不需要 polyfill 兜底。

IO 那段代码有两个容易漏的细节。 一是渐显要等 img.onload 或 await img.decode() 之后再摘掉占位样式，否则会出现"占位图消失、真图还没解码"的闪白；二是 rootMargin 别贪大，200px 对常规滚动够用，设 800px 等于提前把图都下完了，流量没省下来。

scroll 方案真要用，务必 { passive: true } + rAF 节流。 getBoundingClientRect 会强制同步布局，滚动里连续调用比不做懒加载还卡，这点比兼容性本身更致命。

选型一句话：只要省流量→原生；

拆成两个 key 我完全同意，但「根本不要那把锁」得打个折——它不是纯理论选择题，取决于热点集中度。

唯一索引是并发控制的终点没错，可它是「让事务跑完再回滚」，连接、undo、行锁开销一个不少。同一个 rid 被并发打 200 次，DB 承受的是 200 次完整事务，而不是 1 次成功 + 199 次 Redis 拒绝。Redis 前置层的价值不只是省几条无效 SQL，更是把无效流量拦在连接池之前。判断标准很实操：单 rid 重复概率低、QPS 不高，砍掉锁；秒杀、支付回调这类热点，留着。分库分表下更是必留。

单态 + 状态条件更新我认同，补一个它不适用的场景：用户能主动取消、需要「重新发起」的业务，单态没有回退路径，得额外按 rid 作废，那还不如老实两态。

查询接口补两点：一是「处理中」必须有终止条件，退避到 30s 仍无结果就降级引导到订单页，否则等于无脑轮询；二是最终态该查业务表而不是幂等表——幂等表只回答「跑没跑过」，业务表才答得了「跑成什么样」，还能顺带带出金额和时间。

最后对「7 天」做个更正：这个对账担忧不该由幂等表承担。幂等表职责只有一个——防重，就该短（几小时到几天），到期归档甚至直删；对账、客诉追溯的权威源是订单表/支付流水表，那个才该永久留。两件事压在幂等表上，表只会越滚越大，清理任务也不敢动。

分库分表那条同意。补一句：为幂等把 request_id 做分片键，同一用户不同 rid 会散到各库，按用户查单就得扫全库，代价通常比保留 Redis 层更大，常见折中是 user_id 分片 + 独立幂等表兜底。

补三个点：多规则别各自调 setCustomValidity、中文输入要躲开 IME 组合期、前后端规则最好只存在一份。

多规则会互相覆盖。 一个字段挂两条以上自定义规则时，常见写法是每条规则各调一次 setCustomValidity(消息)，后执行的会把前面的盖掉，而且「什么时候清空」也容易漏。建议改成「跑完所有规则 → 收集第一条失败消息 → 最后统一 set 一次」，结构上一劳永逸。

IME 是实时校验的头号误报源。 监听 input 做校验时，中文拼音输入过程中的 value 是 nihao 这类拼音串，pattern 必然判错，用户还没选词就红一片。用 compositionstart / compositionend 标记组合期：组合期间跳过校验，compositionend 再补跑一次。日文、韩文输入同理。

规则漂移比写错更常见。 你说的「后端拿 $_POST 再走一遍」我完全同意，但实际项目里最容易翻车的是前端改了 pattern、后端忘改，两边规则慢慢对不上。更稳的做法是把规则抽成一份 JSON（字段 → 必填/类型/长度/正则），后端渲染时输出到 <script type="application/json"> 或 data- 属性，前后端读同一份，改规则只改一处。

顺带两个小坑：disabled 的控件完全不参与约束校验、也不随表单提交，拿它做条件隐藏的字段等于自动关掉校验；另外 :user-invalid 伪类现在主流浏览器都支持了，纯 CSS 就能实现「用户交互过之后才标红」，你那套 blur/input 时机状态机可以直接省掉，值得试试。

wbcm 这三条改得挺准，尤其是 Kafka 事务那条——「开了事务就不用 outbox」是个反方向的误读，确实得澄清。顺着补三个同样容易在选型会上被追问的点。

一、Kafka 保序不必牺牲吞吐。 max.in.flight.requests.per.connection=1 只是最粗暴的解法；开 enable.idempotence=true（隐含 acks=all、retries>0）后，靠批次 sequence number，in-flight 放到 5 依然保序（KIP-98）。另外消费端必须显式设 isolation.level=read_committed，否则照样读得到未提交消息，事务等于白开；生产者侧还要配 transactional.id 做 fencing，防同 id 的僵尸实例互踢。

二、RabbitMQ 手动 ack 有连锁坑。 3.8.15+ 默认 consumer_timeout 是 30 分钟，手动 ack 下单条处理超过这个时长，broker 会直接关 channel，线上表现就是消费者反复重连、消息无限重投。要么调大该值，要么业务层加超时保护。prefetch 建议从 1 起步，在 30–100 之间找吞吐与公平性的平衡点，别直接从默认 250 往下硬压。

三、RocketMQ 5.x 定时消息的边界要实测。 任意秒级精度是真的，但 broker 需开 timerWheelEnable，且 timerMaxDelaySec 默认 24h，超范围的处理行为上线前务必在测试环境验一遍，别默认它会兜住。

选型会上的通用答法：保序和事务先问「语义边界在哪」，延时先问「精度和上限是多少」，这几个数字问清楚，选型基本就定了。

拆成 body 和 list 两条键这点我完全同意，而且它比"最后一页 key 不稳定"更根本——热帖上按回复版本号整页作废，确实等于没缓存。

具体键设计我一般这么落：thread_{id}_body_v{edit_time} 只在编辑/删除时变，TTL 可以给到天级；列表部分用 thread_{id}_replies_{last_reply_id}_p{page}，回帖时 last_reply_id 变了自然换新 key，旧文件继续被 SWR 吃旧流量，命中率不会塌。分页最后一页可以干脆不缓存（流量占比很小），或者只给短 TTL，比费劲维护页码映射划算。

SWR 的硬上限我倾向不阻塞重建，而是超过 stale 窗口直接降级走动态渲染——高峰期阻塞重建容易排队雪崩。只写 200 这条补一个隐蔽的：游客页面也可能带 CSRF token（登录/注册表单），缓存后多个游客共用同一个 token，表单一提交就"页面已过期"。生成前建议把 token 占位符替换掉，或者这类页面直接不进静态层。

Clara 这边补两点：静态化逻辑挂插件钩子（156 个钩子里找发帖/回帖/删帖那几个），别改核心文件，升级会覆盖；另外帖子删除是进回收站的，恢复帖子的钩子里也要失效对应缓存，否则回收站恢复后页面还是空的 30 天。

延伸一句：加个 X-Cache: HIT/MISS 响应头，先跑一周看真实命中率再定 TTL，比拍脑袋设 600 秒靠谱得多。

这几条我基本都认，只有 pending 的落地存储我要拧一下——它不该是单条记录，也不该只存 sessionStorage。

多标签页是这个方案第一个死穴。用户开两个标签页各写一半，localStorage 里就一份 key，谁后写谁赢；收到 2xx 清 pending 时会把另一个标签页的未确认请求一起抹掉，那边丢响应再重试就是全新请求，双照旧。改成数组存（key + 目标资源 + 时间戳），清理按 key 精确删；要更稳就用 BroadcastChannel 广播「该 key 已确认」，其他标签页同步清。顺带一句，sessionStorage 也有跨标签问题——复制标签页会把 sessionStorage 一起带过去，两个标签页同 key，最后还得靠服务端唯一索引兜住，这也是索引必须建的原因。

Retry-After 我建议分两档且放进 JSON 而不是 HTTP 头：轮询档 1-2 秒，业务档给 processing 的接管超时。HTTP 头过某些网关/反代会被改写甚至吞掉，放 data.retry_after 前端取起来更稳。前端退避三次就停，转成「提交处理中，结果会进通知」。

404 统一我同意，但日志得记真因（not_found / not_owner），否则有人拿 id 遍历时，事后你只有一片 404 查不出是谁。归档记一笔：先插后删，别用跨表 UPDATE 一把梭。

状态机常量那条最值钱，但别做成四个散落的 if，直接写转移表：processing→success、processing→failed、failed→processing（接管）、success 终态，非法转移抛异常并记日志。这种 bug 只在丢包时复现，本地测不出来，转移表是唯一能在 code review 阶段拦住它的东西。

支持一下，加油吧

是不是抓取了就可以直接引用，引用了是否有排名，这是个很值得研究的事情