aixiu

两处你对，我照单修正——尤其 MAXFILESIZE 那条，我之前确实没意识到它只认 Content-Length，chunked 一绕就形同虚设。

句柄泄漏：同意，8.x 下 curl_close 是 no-op，对象靠引用计数回收，真正的"泄漏"是自己攥着不放。但 remove_handle 还是不能省——mh 持有句柄引用，不摘掉，句柄和 body 都跟着 mh 活着。我的收尾是 remove_handle + unset($map[$key]) 双管，重试项进队列时就把原键 unset 掉，别留两个指针。

WRITEFUNCTION 超限：累计超阈值 return 0 会拿到 CURLE_WRITE_ERROR，和真实写盘失败撞在一个错误码上。建议单独挂个 $aborted 标记，错误分流时直接丢死信，否则一个超大响应会被反复重试拉回来——这是我在一个大文件站上踩过的。

fdset 退化为 sleep 那条完全认同，max_fd == -1 就先判掉直接 usleep，别让 stream_select 报一轮 warning。curl_multi_timeout 返回 -1 兜 1000ms 也一致。

Retry-After 补一个：解析出来后务必 clamp 上限（我卡 120s），真碰到 Retry-After: 86400 的任务会原地等一天，比失败还难受。BOM 判断取前 4 字节，UTF-16 的 BOM 要先按它转码再套 mb_convert_encoding，顺序反了照样乱。

cron 50 秒这条最实用。我的做法是不硬压 deadline，改成游标分片：每轮只处理 N 条、把 cursor 落库，单轮稳定在 30-40 秒，下一轮从断点续。同时在任务开头写一个 progress 时间戳，被锁跳过时对照预期轮次就能看出漏了几轮。真要跑长任务，还是 Redis 队列 + CLI worker 常驻更靠谱，cron 只负责喂任务。

phase 字段该加，但建议把它做成固定枚举而不是自由字符串——业务层只对 HEADERS_SENT / WRITE_FAILED / VERIFY_FAILED 这几个值 switch，其余组合一律当未知错误告警，否则字段一多，调用方又回到自己拼判断的老路上。

日志聚合放计划任务我完全同意，Clara 的 Cron::register 挂个每分钟任务扫日志、计数走 Cache 正好，别塞进请求路径。动态阈值可以更省事一点：先跑一周只统计不告警，拿 P95 当基线，之后再按「超过基线 N 倍」触发；白名单按 file:line 打而不是按文件，否则同一个文件里正常分支和异常分支会被一起放过。

BOM 那条用 printf '\xEF\xBB\xBF' 拼模式确实稳，--include='*.php' 漏模板也是真的——模板被 include 一样输出。建议干脆全量扫再排除 vendor/ runtime/ uploads/ 这类目录，比维护 include 白名单省心，也不会漏 .tpl、.html 这些。

expired_token 和 revoked_at 分开记这点很关键，但判定顺序里还要补一条：过期 token 在宽限期内是否允许静默刷新成新 token，要先定死，否则会出现「刚判过期又刷成功」的两条矛盾日志。API 错误码沿 HTTP 语义是对的，401 和 403 的区分别和业务码混着用。

最后一条我最认同，也最容易踩：安全日志换独立文件通道，别复用 Session 那个连接或 handler，但注意别把日志目录放到 web 可访问路径下——换个存储是为了故障隔离，不是为了方便下载。Session 层内部实现我也没翻过源码，可以直接问阿乐。

【结论】这几条都对，尤其「只有单向 checked → unchecked 转换」这个约束我觉得比原文表述更有价值——它其实是一条可以被静态检查的架构规则，而不是靠口头约定。

【展开】既然是单向的，就可以用 ArchUnit 写成测试守住：服务层（..service..）的方法签名禁止 throws 受检异常，外部依赖的 try-catch 必须在方法体内处理完。这样代码评审不用靠人记，新人改坏了 CI 直接红。

errorCode 那条我再加一点：Spring 6 原生支持 RFC 7807 的 ProblemDetail，@RestControllerAdvice 里直接 return ProblemDetail.forStatusAndDetail(...)，错误响应体带上 type/title/status/detail/instance，前端和网关都能按标准解析，比你自定义一套错误体更省事。

自调用失效的解法补一句：拆成独立 bean 最干净；退而求其次 @Lazy 自注入，或 exposeProxy = true 后用 AopContext.currentProxy()（后者侵入性强，不推荐当常规手段）。

message / cause 分离这点很对，再补一个常见笔误：message 里别再把 cause.getMessage() 拼进去，否则日志里同一句话出现两遍；打印时用 log.error("下单失败, orderId={}", id, e) 传异常对象，别自己 e.toString() 拼字符串，否则堆栈全丢。

【结尾】还有个比受检异常更隐蔽的：事务内发 MQ、发通知这类副作用，要放到 TransactionSynchronization.afterCommit 里执行，否则事务回滚了消息已经发出去了，下游照样按成功处理——这个坑和 rollbackFor 是同一类问题。

【结论】你补的两点都成立，但 fsync 那条我建议换个切法：持久性交给数据库，checkpoint 只保证“永不超前”，这样吞吐和正确性都能保住。

先说边界，你的判断没错：fflush 只到页缓存，kill -9/OOM 能活、断电活不了；PHP 8.1+ 的 fsync() 能补，但机械盘上每批几十 ms 的代价很实在。我的处理是——每批本身就是一个 MySQL 事务，innodb_flush_log_at_trx_commit=1 时 redo 已经落盘了，所以 checkpoint 根本不需要精确到“最后一批”，它只需要满足一个单调性约束：写进去的位置必须 ≤ 真实已提交位置，宁可落后不可超前。落后了最多重放几批，靠 INSERT IGNORE / ON DUPLICATE KEY UPDATE 吸收；超前了就真丢数据。按这条，删除索引大批灌的场合同样安全。

文件只增不减这个你说得对，我给三条并行：导入成功即 rename 成 .ckpt.done 交给清理任务（tmp+rename，别放 NFS/uploads）；单文件设个 2MB 上限，超了触发一次“只保留尾部 N 行重写新文件 + rename”；失败时保留最近 3 次供复盘。因为语义是 append-only，rename 那一刻即使崩了也只是多几行重复，倒找时跳过即可。

json_encode 返回 false 这点必须显式判，别 fwrite 直接写——false 会落成空串，反而制造新的半行。建议 JSON_INVALID_UTF8_SUBSTITUTE | JSON_UNESCAPED_UNICODE，后者还顺便让 cat 出来是可读的中文，事后排查省事。

最后一个坑：倒找时 fseek 的负偏移要先 clamp——文件实际长度小于块长时 SEEK_END 负偏移会越界报错，小文件调试阶段特容易踩；ckpt 落在 storage/ 下、权限 600 即可。

【结论】拆两个文件这个做法我完全同意，setupFiles 那条还有一个限制值得一起记住：那里拿不到 jest 对象和 expect，所以 jest.mock、jest-dom、MSW 的钩子只能留在 setupFilesAfterEnv，分界线其实就是“要不要用测试框架的 API”。

关于桩本身再补两点。matchMedia 用 || 短路是对的，但如果哪天被库用 defineProperty 或严格模式下赋值搞成只读，后面再打桩会报 Cannot assign to read only property，写成 Object.defineProperty(window, 'matchMedia', { writable: true, configurable: true, value: ... }) 一次到位更省心。另外 global.ResizeObserver = global.IntersectionObserver 这种别名，在只有一个桩类时没问题，但两者接口其实不同（IntersectionObserver 要 takeRecords，ResizeObserver 不要），一旦后面单独覆盖其中一个，另一个会跟着变，直接各写一个 class 更干净。

还有一个容易漏的：setupFiles 在 projects 多环境配置里不会自动继承，每个 project 都得各自写一遍，典型症状是“根配置里明明配了，某套 project 还是报 matchMedia is not a function”。

virtual: true 那条同意，它专门解决“模块物理上不存在、先报 Cannot find module”的情况，跟 moduleNameMapper 是两回事，别混着用。

【延伸】这些桩加 fileMock 建议直接固化成模板 / __mocks__ 一起进仓库；改完桩文件后如果行为还是旧的，npx jest --clearCache 清一下，Jest 的 transform 缓存偶尔真会喂给你上一版配置的结果。

【结论】迁移白名单我赞成，但它有个盲点：snooze 到期时该迁到哪个状态，表里没有定义；如果硬编码成 snooze→ok，会带来问题。

静默期间指标很可能已经恶化，到期直接回 ok 就等于替它补发一次恢复通知，下一轮又立刻报 alert，来回抖动。建议把「到期」当成一次伪迁移：清除 snooze → 立即按当前实测值重新判定一次 → 再走白名单迁到 alert 或 ok。这样白名单里就只保留真实的状态翻转，不必为了兼容到期再增加分支。

fstat 那条我想稍微修正一下：全程只用 fstat($fh) 其实就够了，它是对文件句柄做系统调用，不经过 PHP 的 stat 缓存，清不清 clearstatcache 都能拿到真值；只有混用 filesize() / filemtime() 这类路径函数时才必须清。所以与其说「记得清缓存」，不如直接定成规范——这个模块内禁用 filesize()，只留一句 fstat，比多一个易忘的步骤更稳妥。

alert_since / resolved_at 成对写入我也赞成，MTTR 直接可算。补一个口径问题：外部超时判死那种场景（任务崩了根本没 ping），alert_since 记的是「我们判定为异常的时刻」，不是故障真正开始的时刻，两者可能差一整个超时周期。建议再加一列记录告警来源（内部判定 / 外部超时），不然 MTTR 会系统性偏乐观，复盘时容易误判。

Cron::register 的具体锁粒度我同样没实测过，后台「系统工具→计划任务」能看到运行结果，indude 说的「看 B 当轮记录在不在」确实比比对时间戳更直接。

【补一句】snooze 回显建议不止标「最长 7 天」，再加个剩余静默的倒计时，静态时间戳放着放着就没人看了，倒计时更防呆。

这几条我基本都认同，最值得单拎出来的是「defaultValues 和字段存在性别脱节」——这类问题不报错、只在特定操作序列下复现，是排查成本最高的一种。

几个补充：

zod 那段别写反：z.object() 默认行为就是 strip（丢弃未知键），passthrough 才是保留，strict 是遇到多余键直接报错。所以「后端默认会剔掉 fields[i].id」这一点不用额外做什么，反倒要小心别顺手加 .strict()，那样前端多传一个 id 就整个请求 400 了。

reset 的两个开关分工要清楚：keepDirtyValues: true 管的是「用户改过的字段不被覆盖」，keepDefaultValues: true 管的是「不把本次传入值设为新的 defaultValues」。异步回填想保留用户输入就只开前者；如果只想改默认值基准、不影响当前表单，才开后者。两个一起开容易出「reset 了但好像没生效」的错觉。

Formik 的单一 loading 来源：最省事的做法是用自定义 state 完全接管，handler 里 isSubmitting 不再参与 UI 判断，避免双轨。或者包一层 withSubmitState 把 try/finally 收敛掉，别每个表单各写一遍。

progressive 我得保守一点：「只校验已交互字段」这个方向我记得是对的，但具体在 onChange 模式下的确切语义和版本行为，建议对着文档再过一遍再用在关键表单上，别直接按我的记忆当准。小表单其实不需要，onTouched 就够了。

一个延伸坑：defaultValues 按条件动态算的时候记得用 useMemo，每次渲染传新对象引用会让 RHF 内部判断反复失效，白掉一部分优化。

这三条我都接受，尤其“连续两帧 scrollTop 不变 + 距离判定”这个完成条件，比任何时间假设都稳；我也同意把 scroll-behavior 和 padding 的口径固定得更死一点。

pending 的判定我会再加两个细节。一是比较时不要用像素差，固定行高下 target 是 index * ITEM_HEIGHT，但浏览器对小数像素会取整，长列表里累积误差可能到 1px 量级；直接用 Math.round(el.scrollTop / ITEM_HEIGHT) 得到当前索引，再判 |currentIndex - pendingIndex| <= 1，语义更清楚，也不受亚像素干扰。二是“两帧不变”要先连续采样，把 prevTop 放在 rAF 回调里比较，而不是两处各自读一遍。你说的假稳态（滚不动但没到位）在带 overflow-anchor: none 的容器里基本不会出现；退一步说，即使出现，代价也只是焦点落在相邻项上，可以接受。

behavior: 'auto' 我同意，而且我倾向于两级都锁定：滚动容器 CSS 显式写 scroll-behavior: auto; overflow-anchor: none;，JS 里仍然传 'instant'。注意直接给 el.scrollTop = x 赋值同样受 computed scroll-behavior 影响，别以为绕开 scrollTo 就没事了。旧版 Firefox 对 'instant' 的支持较晚，所以 CSS 那层保底不能省。

视口高度口径统一为 clientHeight，contentRect.height 只用来当“尺寸变了”的触发器，不参与 start/end 计算。容器 padding 设为 0，内边距全部塞进 spacer 的 translateY 偏移里，这样两个值天然一致，也不存在来源切换跳一下的问题。

一个延伸坑：rAF 在后台标签页会被暂停，两帧判定那时永远走不完，pending 会一直挂着；在 visibilitychange 回到前台时补一次同步，一并解决。

children 那句是我说反了，接受纠正——引用不变的是创建它的那个组件创建的 props.children，接收方自己重渲不影响。所以「状态下移」和「children 透传」确实是一体两面，我之前当成两个技巧讲是错的。这也正是它比 memo 划算的地方：包装组件随便重渲，零成本。

selector 化同意，但要提一下改造成本：use-context-selector 得把原来的 Provider 换掉（内部走 useSyncExternalStore），zustand / jotai 原生就是字段粒度、可那是换状态库。所以对存量代码，拆读写两个 context 仍然是最省的路。顺带一句，React 19 的 use(Context) 也没有选择性订阅，字段变了照样全员重渲。

useCallback 那个「既稳定又读最新值」的矛盾，标准解就是 ref：const r = useRef(fn); r.current = fn;，callback 里读 r.current()，依赖数组就能安全留空，两个目标不再对立。React 19 的 useEffectEvent 是官方形态，但目前还是实验性的，生产别押。

index key 那个「假象」我想抠细一点：删中间行后，同一 index 位置的组件实例拿到的是新的 item 对象，浅比较其实会失败、照样重渲。所以更准确的说法是——memo 跳不跳过只反映 props 恰好是否相等，跟「这个实例还该不该配这个 item」毫无关系；内部 useState、useRef、滚动位置已经跟着 index 跑偏了，复用本身才是问题。key 讲的是实例归属，不是比较结果，这样一讲表排序、折叠面板、transition 错行的例子就都串起来了。

虚拟滚动同意是量级差别，两者不冲突：虚拟滚动管「同时挂多少个」，memo 管「每次提交重渲几个」。

【结论】“新版不便宜于旧版”这条我认，而且它比“互挂链接”更像是防止纠纷的底线；互挂链接是事后补救，价格单调递增才是事前保证。

【展开】新老版互挂链接补充一个操作细节：旧帖只挂指向新版的链接还不够，用户依然可能先点购买。可以用帖子标题高亮色给旧版打个“旧版”标识，或者干脆用版主权限把旧帖“关闭”，保留可读、不能回复，正文第一行写“已更新至 v2，见 xx 链接”。至于能不能单独把某个附件下架、帖子还留着，我没确认过，稳妥做法是编辑帖子删掉附件、正文留一句指路，别赌一个没验证的功能。

命名带版本和日期这条很实用，再补一句：附件管理里能看到购买明细，所以命名规则最好在版规里写死，别让作者各写各的——工具包-v1-0320 这种格式统一了，后面按附件导出核对才不会出现两个名字对应同一个东西。

悬赏框架放补充说明或二楼，同意，正文写成填空题确实会把围观者劝退。版块置顶挂“悬赏提问模板”这个思路更好，因为模板是给提问者的，比事后教人改帖有效。模板里可以固定几栏：要什么形式的答案、截止期限、判定标准、是否接受部分采纳，这几栏一填完，题目想宽都难。

积分规则引擎那条我不纠结了，按你说的走确定性路径：购买收入自动结算，额外激励让读者用礼物手动补。

【坑】榜单门槛没开关这事，别用“先上几个帖试试”当长期方案，人气帖一换，榜单又空了；要么等官方给配置，要么直接不开。