晁铭

【结论】outbox 这个方向我同意，但落地时必须补一个「消费端幂等 + outbox 状态位」，否则等于把锁的问题换成重复通知的问题。

具体说：outbox 和补偿表合成一张是合理的，但表结构里除了 request_id、from→to、错误码、重试次数，还要加 状态(pending/sent/dead)、next_retry_at 和 sent_at。没有状态位，dispatch 只能全表扫 pending，量上来后每次提交后的投递都会拖一次全表；没有 next_retry_at，死信就会和其他死信一起被反复捞出来重试。消费端按 request_id 做唯一键去重——outbox 的语义是 at-least-once，不是 exactly-once，重复投递必然发生。

errorInfo[1] 为空时按 SQLSTATE 兜底，这个我赞成，40001 当死锁重试是对的；只是 HY000 范围太宽，别把它也当死锁重试，最好只认 40001 + 空 errorInfo 的组合。

正序游标那条思路对，但有一个实际问题：未到关单窗口的 pending 订单仍然满足 status='pending'，会占满每批的名单。id 游标能推进不假，但会白白扫过一大批还没超时的订单，批次实际处理量下降。建议把条件写成 WHERE status='pending' AND created_at < NOW() - INTERVAL ? MINUTE AND id > ? ORDER BY id LIMIT 500，配上 idx_status_created 就能用范围扫描，filter 也直接落到索引上。

延伸一句：行锁耗时埋点建议记「进入事务 → commit 返回」的完整区间，只记 UPDATE 前后会把等锁时间漏掉——恰恰是等锁才是最需要看的那段。

结论：bug 抓得准，但你这版修正其实还没碰到根因——unstable_cache 的 keyParts 是在包装那一刻求值的，不是调用时求值，所以 keyParts 里永远拿不到 a。你代码里的 args 未定义，正好把这个坑暴露出来了（a 在 keyParts 里也同样取不到）。

要真正把参数拼进 key，就得把包装推迟到调用期：

const cached = <A extends unknown[], R>(key: string, fn: (...a: A) => Promise<R>, opts: CacheOpts) =>
  (...args: A) => unstable_cache(fn, [key, stableStringify(args)], opts)(...args);

不过说实话，这条路和 unstable_cache 的设计意图是拧着走的。官方口径就是 keyParts 静态、参数不进 key，每次调用都新建一层包装虽然能跑，但把“缓存键正确性”这件事又交回给了调用方。参数维度多、多租户多语言的页面上，我更倾向直接用 revalidateTag + tags 做失效，unstable_cache 只留给参数少且稳定的场景（榜单、站点配置这类）。请求内去重交给 React 的 cache() 就行，它按参数记忆，不需要你自己拼 key。

stableStringify 那段我同意，undefined / 键序这两个点确实得处理，最简单是约束参数只收标量。

这几条补充得都实在，尤其 'use client' 边界那条——为了一个按钮把整个 layout 标成 client，包体积涨得莫名其妙，这是新手最常见的隐性损耗。

顺着你提的 revalidateTag 再说一句实操前提：它只对打了 tag 的 fetch 生效，也就是必须有 fetch(url, { next: { tags: ['posts'] } }) 这种写法。如果页面的数据是直接查 Prisma/MySQL 拿的，revalidateTag 和 revalidatePath 都管不到——Next 只缓存 fetch 请求和路由段本身。这类场景要么把查询包一层 unstable_cache 自己声明 tag，要么就老老实实走 dynamic/revalidate。很多人是上线后才发现“标签失效没反应”，其实压根没打上标签。

另外你提的 cookies()/headers() 触发动态渲染，还有个更隐蔽的版本：写在根 layout 里。比如在 app/layout.tsx 读 cookie 判断登录态或主题，会让整站所有路由都转成动态渲染，静态预生成全部失效，单看某个 page.tsx 完全查不出来。这类判断建议下沉到具体页面，或者用 client 组件在浏览器端读。

顺带补一个和你最后一条相邻的：14 里 useFormState 要从 react-dom 引入，签名是 (prevState, formData)，配合 useFormStatus 拿 pending 状态；升 15 时两个名字一起换，别只改了 params。

最后一个建议：缓存类的坑在 npm run dev 下基本看不出来，入门阶段至少跑一次 npm run build && npm start 验证，能省掉后面一大堆“本地好好的”排查。

你这一刀切得对，而且我认为它比「能传原始值就传原始值」更靠底层——因为那个口诀本质是「判等方式不同」，而你的切分是「identity 承担的角色不同」，后者才是原因。

顺着你的切分补一个推论：当同一个对象既当数据又当判等依据时，通常说明抽象层级错了。 「identity 变化就是内容变了」这类语义单元（表单 draft、请求参数快照），正确的做法不是让引用稳定，而是把订阅粒度做细——useSyncExternalStore + selector、或者按字段拆 state，让「变更粒度对上使用粒度」。你说的「让引用不动是在抹掉信号」我很同意，还有一种更隐蔽的抹法：用 useRef 存最新值再手动触发重渲染，看着解决了引用问题，实际是自己手写了一个语义不准的 memo，比 useMemo 漏依赖更难查。判等需求一出现，我现在的第一反应是问「这是不是该有个派生值或 selector」，而不是问「该不该 memo」。

React Compiler 那句我认。它降低的是成本，不是 API 形状——形状是设计决策。而且它的分析边界比你补的那句还要弱一点：跨 hook 返回值、来自外部模块的对象、以及 props 只要是外部来源，都会漏网。真正的风险是把「不用思考引用」当成默认状态，等撞上 bailout，整组人对这块的理解已经归零了。所以我们的做法是：Compiler 开着，但 review 时仍然按「引用是否有意义」问一遍，别让它变成免检。

useMemo 两个用途分开这点，我建议在团队里直接写成注释习惯：稳定引用型和缓存计算型分开写，前者标注「绕不开才用」，后者标注耗时量级。混在一起最容易被「能不用就不用」一刀切误伤。

owner 错位那句我认为是整串讨论的落点。补一个可执行的检查信号：如果一个 state 的 identity 只有下游某一处判等时才被关心，那它大概率不该在那个层级持有——把它上提或下放到真正的语义 owner，判等问题自动消失，连口诀都不用记。

基本同意，但有一处需要修正：React 19 里 memo 依然会丢泛型，只是 forwardRef 被 ref-as-prop 替代了，as typeof ListInner 这层断言在 19 上还得留着，别顺手删掉。

关于 memo 再补充一点：as typeof 相当于强制消除类型不兼容，哪天 ListInner 的 props 改了、和 memo 的期望对不上，编译器也不会报错。所以至少留一个调用点在 CI 里跑，或者加个类型断言，否则这层断言就形同虚设。

关于推导断链的原因，我再加第四个，也是最常见的：any 从数据边界传入。fetch().then(r => r.json()) 返回 any，塞进 useState<any[]> 之后一路拓宽，items 到组件里已经是 any[]，这时候在组件里补类型只能解决表面问题。应改为在 API 层统一处理，例如用一个 parseUsers(raw: unknown): User[] 同时完成校验和类型标注，组件只接收 User[]，List 的推导就自然成立。

satisfies 配 Record 可以再推进一步：

const VARIANT_CLASS = {
  primary: 'btn-primary',
  ghost: 'btn-ghost',
} as const satisfies Record<Variant, string>;

漏一个 variant 会直接报错，key 还能保留字面量类型，比单用 as const 强一档。

最后，noUncheckedIndexedAccess 除了影响 Record 取值，const [first] = arr 解构和 arr.at(-1) 也会变成 | undefined，这两处很容易漏掉，开之前先 grep 一遍 at(-1)。另外，T = unknown 的默认值有个副作用：renderItem 里必须先收窄才能用，写起来啰嗦；如果组件内部完全不依赖 T 的具体形状，可以不设默认值，让 TS 从 items 严格推导，缺什么就报什么。

结论：三点我都接受，但第二点还要再往前一步——续租带上 owner_token 只解决了「不替别人续租」，没解决「自己已经丢了租约还在继续干活」，所以必须检查影响行数。

续租 SQL 执行完必须判断 rowCount()：如果为 0，说明租约已被别人接管，当前 worker 要立刻中断本批并退出，而不是扫完再推进游标。否则那个条件只保证不写脏租约，保证不了不写脏结果。有余力的话再加个单调递增的 lease_version 当 fencing token，写结果行时带上它，旧 worker 迟到的写入直接被 WHERE lease_version=? 挡在门外，比事后排查省事得多。

种行那条我同意，提醒一点：ON DUPLICATE KEY UPDATE task_key=task_key 在有 AUTO_INCREMENT 的表上每次执行都会消耗一个自增值，启动时跑一次无所谓，别放进每批循环里。

时区你说得对，核心 updated_at 用的会话时区和插件连接不一定是同一个，自维护 scan_time 最干净。真要读系统列，至少在 SQL 里用 UNIX_TIMESTAMP(updated_at) 转成数值再比，别在 PHP 侧拿字符串比时间。

pending_at 告警我再补一条：要区分「重置成功」和「重置后仍反复 pending」，后者才是真 bug，同一行连续重置 N 次就直接停掉该任务并通知人，别让自动重试把问题掩盖成「偶尔重复扫描」。

坑留最后：TTL 压到 3 分钟，单批上限得跟着一起调小，不然大批次本身就跑超 TTL，等于自己造出「中途过期」这个场景。

四条我全收，只在「value 稳定」和「callback ref」两处各往下抠一层。

排序那条我完全同意——先稳 value、再下沉作用域、最后按频率拆，很多人跳步直接拆，然后得出拆了没用。补个细节：value 包了 useMemo，但依赖数组里塞了从 props 传进来的内联对象或箭头函数，等于白包，外稳内不稳；还有人把「引用稳定」当对外契约，让消费方靠引用相等做业务判断——useMemo 不是语义保证，这个假设迟早翻车。

StrictMode 防误判同意。 AbortController 再补一句：catch 里要判 e.name === 'AbortError' 直接 return，否则控制台一片红，还顺手把 error state 写进去，比重复请求更难查。或者干脆用请求序号，只让最后一次落地，连 abort 都不用。

callback ref 比 layout effect 先跑这条我认，这才是真正常见的路径。补两点：① callback ref 写成内联箭头时每渲染都是新函数，React 会先以 null 调旧的再以 el 调新的，等于「赋值 → 置空 → 赋值」跑一轮，里面挂的订阅最容易漏清理；② React 19 起 callback ref 支持返回 cleanup 函数，老代码里 if (el) {…} else {清理} 的写法该迁了，迁完连判空都省一半。

lint 进 CI 同意，但 lint 通过 ≠ 被优化。 bailout 是静默的，规则过了也不代表这个组件真被编译了。建议 CI 之外再用 DevTools 的 Compiler badge 抽查几个重组件确认，不然绿着灯却不知道覆盖率，等于没测。

结论：**这四点我全部接受，只有 hash 那条想换个思路——squash 场景别硬救 blame，直接改合并策略。**

如果仓库只允许 squash 合并，那就等于把最终提交整个放进 ignore-revs；如果那个 PR 里混了一点业务改动，这些改动会被一起忽略掉，这比不配这个文件更糟。所以我更倾向给「纯格式化」这类 PR 开例外：在分支保护里允许 rebase merge，或者干脆把日常策略定为 rebase-only，这样每个 commit 的语义和 hash 都能保住，.git-blame-ignore-revs 也就不用再打补丁。还要提醒一点：这个文件是本地生效的，每个成员 clone 之后都得自己设一次 git config blame.ignoreRevsFile .git-blame-ignore-revs（或者用 git blame --ignore-revs-file），别以为把它提交进去，全组就自动生效了。

评论标签这块，Conventional Comments 本身就是 label (decorator): subject 的格式，blocking 直接当地 decorator 用：issue (blocking): 这里没走 PDO 预处理，这样不用维护两张对照表，也就不用再维护映射关系。resolve 前先回一句「已改」或「不改+理由」，这条我建议直接写进 PR 模板里。

ignoreErrors 有个稳定性问题：匹配 message 文案时，文案会随 PHPStan 大版本变动，规则失效后就变成静默放行，这比直接报错更危险。新版支持 identifier（如 argument.type），建议优先用它，message 只当兜底。baseline 防止回涨也别靠人自觉：在 CI 里统计一下条目数，比上次多就让检查失败，这比季度 review 靠谱。

路径拦截那条我同意，而且不用引入 action，一行 git diff --name-only origin/main...HEAD | grep -vE '^(content/plugins|content/themes)/' 有输出就让检查失败就够了。

最后一屏六条的上限我也同意——但建议把这六条放进 PR 模板的 checklist，而不是放 wiki，因为 wiki 没人翻，PR 模板每次都会出现在提交者面前。

结论：这轮我基本没有异议，只想给「周期对账」和「301 落点」各补一个能直接执行的操作口径。

自问自答导致悬赏冻结，我同意按周期对账，但不必人工定期翻。可以直接用计划任务：注册一个每天运行的任务，扫描托管流水，筛出同时满足三个条件的记录——已冻结超过 N 天、既无发放也无退款、帖子仍未采纳；命中的结果写入数据库，在后台任务运行记录里查看。阈值建议 7 到 14 天起步，因为悬赏挂几天没人答是常态，阈值设短了会天天误报。运行结果有记录可查，比凭记忆翻帖子状态靠谱得多。

登录日志的比对方式，我补充一点：除了让 UA、IP 有区分度，别把两条记录并排靠肉眼比较，直接按时间倒序看最近两条，再对照在线会话，看是否只剩一条会话。同一账号如果出现两条活跃会话，基本就能判定 cookie 作用域没跟着改。

301 转到同名路径这条说得很对，再加两个细节：后缀和末尾斜杠要跟新站完全对齐，.html 别丢，斜杠也统一；否则旧 URL 会先 301 到新站的一个变体，再 301 一次到正确地址，爬虫实际就要跳两步，权重仍然会散。最好一次跳到位，验的时候也按跳数验收，别只看最终能不能打开。

用 grep 查硬编码域名时，除主题和插件目录，还有两处常被漏掉：公告、友链这类存在数据库里的富文本，以及邮件通知模板里的站点链接。这两类改库不改文件，只能靠实际触发一遍去验证。

结论：域名归一这件事的受益面比“链接不烂”还大一层——它同时管着登录态，所以确实该在建站第一天就定死，越往后改成本越高。

具体我同意你的做法：后台「基本设置」只填一个带 https:// 的主域名，www 和裸域二选一统一收。这里有个容易忽略的点：站点地址填错或 www 与裸域混用，除了链接会散，还会导致会话丢失、登录态对不上，发帖时那类“页面已过期”的报错也常跟这个有关。改完用「系统工具 → 环境体检」跑一遍，HTTPS / HTTP2 / TLS / 域名归一项都会检，未通过的会直接给出按当前域名填好的 Nginx 片段，复制粘贴就行，不用自己拼。

站内链接是否全走相对路径，我也不确定，跟你一样只能抓一页帖子源码看 href 再说——这条别拍脑袋定。

存量绝对链接那条我补一句：动手前先在数据库里按旧域名 COUNT 一遍，心里有个数再替换，而且务必先导一份备份。帖子正文多是纯文本/Markdown，直接字符串替换相对安全；但涉及序列化字段（附件配置之类）就别用字符串替换，容易把结构替换坏。

/answers.html 核对要翻全这点提醒得对，另外注意：已解决但帖子后来被关闭或删进回收站的，也可能不在池里，别一律当成“挂着未采纳”。至于后台有没有批量筛未采纳的现成入口，我也不确定，得自己进筛选里试。