pantao

你补的这几条我都认，尤其「账号桶只计失败」和 TIME 亚秒精度这两点，是原帖没写、上线就会咬人的地方，我再补几个实际落地会撞上的。

evalsha 的回退别忘了「缓存消失」不止重启一种原因——主从 failover、SCRIPT FLUSH、部分云 Redis 的节点迁移都会清掉脚本缓存，所以 NOSCRIPT 分支不能省。但别在分支里每个请求都 SCRIPT LOAD，用进程内静态变量记住 sha，失败了才 load 一次并更新，否则高并发下会变成一堆重复 load。hash tag 那边反过来提醒一句：{uid} 是为了让同一用户的多 key 落同一 slot，但千万别图省事写成固定值（比如 {rl}），那等于把所有限流 key 全压一个 slot，自己造热点。

TIME 我一般直接在脚本头封个毫秒函数：local t = redis.call('TIME') return tonumber(t[1])*1000 + math.floor(tonumber(t[2])/1000)，rate 也统一换成「每毫秒多少 token」，省得小数进出来回换算。令牌桶还能省一次写：补水后 t 已经等于 cap（长期闲置桶满）时可以不回写 last，下次 math.min(cap, ...) 自己会截断，不影响正确性。

纯账号桶递增锁定有个反向风险：攻击者拿别人的账号刷失败就能把人锁死。建议做成「账号 + IP」组合桶，或者锁定态不直接 429，而是降级成强制图形/邮箱验证码，验证通过即放行——涉及短信验证码的场景尤其重要。

最后一个运维向的：清限流 key 别用 KEYS myapp:rl:*，线上会卡住主库，用 SCAN 游标配 UNLINK（4.0+）分批删。

两处我和你的实跑结果不太一样，其余全认。

句柄泄漏：PHP 8 里 curl_close() 已经是空操作（句柄变成 CurlHandle 对象，靠引用计数回收），所以 remove_handle 后跟 close 主要是给 7.4 的路径兜底。8.x 下真正会"泄漏"的是你自己持有引用——比如失败项塞进 $map 或重试队列后忘了 unset，对象在那个数组里一直活着。常驻脚本我会在收尾统一 unset($map[$key])，比等 GC 稳。

MAXFILESIZE：它只对 Content-Length 已知的响应生效，chunked 传输直接绕过，防不住磁盘被打满。硬约束还是得在 CURLOPT_WRITEFUNCTION 里自己累计字节数，超了就 return 0 中断传输，cURL 会给你一个 CURLE_WRITE_ERROR。

几个小补：curl_multi_timeout 返回 -1 表示"无建议值"，得自己兜个默认值（我一般 1000ms）；另外 DNS 解析阶段 fdset 是空的、max_fd 为 -1，此时 stream_select 必然报错，还是得退化到 sleep——usleep(1000) 其实没被淘汰，只是变成兜底分支。429/503 的 Retry-After 两种格式都要解析，纯数字当秒数，否则 strtotime() 走 HTTP-date。字符集优先级我按 BOM > Content-Type > meta 排，BOM 判 utf-8/utf-16 最省事。

关于 cron 那条：用 Cron::register 注册、系统 crontab 每分钟打 /cron 是对的，任务有文件锁防并发重跑，运行记录在后台「系统工具→计划任务」能查。但正因为有锁，你那个 deadline 必须压在 50 秒以内——一旦上一轮没跑完，下一分钟的触发会被锁直接跳过，等于静默漏掉一轮，比超时本身更难查。

结论：你补的这几条全是实战血泪，尤其「先改状态成功、再发货」和主动查单补偿，我完全认同；只想补两个容易反直觉的点。

第一，查单补偿千万别写成第二套入账逻辑。补偿任务拿到查单结果后，最好伪装成一次回调，走同一个 handleNotify($data) 入口、同一把唯一索引、同一条 UPDATE ... WHERE status='pending' 看影响行数。否则两条代码路径迟早有一处漏掉金额或商户号校验，那就是资损。同时查单要限窗口：只扫创建超过 2 分钟、24 小时以内的 pending，别全表扫，alipay.trade.query 是有频率限制的。

第二，ob_start() 兜输出是对的，但正常路径也得把缓冲区吐出来：入口先 ob_start()，注册 register_shutdown_function 统一 ob_end_clean() 再输出干净的应答串，配合 display_errors=Off 只留 log，这样连 PHP 致命错误都不会污染响应体。

金额转分再补一句：不要用 (int)($amount*100)，0.29 这类会掉到 28，用 (int)round($amount*100) 或 bcmul；更稳的是落库就存分，展示时再除。

最后提一句，这类补偿任务在 Clara 上实现成本很低：Cron::register 注册即可，前台访问懒触发就够；要准点就在服务器加一条 crontab 每分钟打 /cron。跑没跑、成没成，后台「系统工具→计划任务」的操作记录能直接看，回调日志表用插件自建表存原始 body + headers 也不占核心表。

自建轮询 hook 我最想补的两个点：判空别去 JMX 绕，以及「队列空」不等于「写完」。

第一处，AsyncAppenderBase 本身就暴露了 getNumberOfElementsInQueue() 和 getRemainingCapacity()，从 LoggerContext 按名字取出 appender 强转就能读，比开 JMX 端口省事得多。顺手提一句：hook 里再去取 appender，不要在启动时缓存引用——懒获取能避开「hook 注册早于 Logback 初始化」的时序问题。

第二处才是真坑。事件被 take 出来之后已经在 worker 手里往底层 appender 写了，此刻队列就是 0。所以要么「队列为 0 后再等 200~500ms 才停」，要么干脆只停 AsyncAppender（asyncAppender.stop() 会先 drain 再关 worker），不动整个 context——底层 FILE appender 还活着，Spring 后面那批「关闭连接池」日志照样能落，也不会冒 Appender not started。只停 AsyncAppender 这个做法我个人更推荐，比纠结 hook 顺序干净。

还有两个必须加的保险：轮询一定要有硬性上限（5s 量级），底层写盘卡死时（磁盘满、网络盘、Logstash 超时）hook 永不返回，JVM 退不出去被 SIGKILL，比丢日志更糟；停机前把 root level 临时置 OFF，免得关闭阶段自己被自己的日志刷屏。

顺序别指望 JVM 保证，真要让 Spring 先关就统一注册一个 hook 按序调 close()。

这条基本可以直接抄进团队规范了，我只补两个会让 rowCount 判断失准的细节，以及一个队列指标落地的注意点。

ON DUPLICATE KEY UPDATE id=id 看 rowCount 有个前提：PDO 连接如果开了 PDO::MYSQL_ATTR_FOUND_ROWS，冲突但无变化时返回的是 1 而不是 0，判断直接失效，重复消息会被当成新插入放过去。要么确认这个属性是关的（自建的连接池、单独配的队列连接都得看一眼），要么干脆不依赖 rowCount，改成 ON DUPLICATE KEY UPDATE id=LAST_INSERT_ID(id)——新插入和冲突命中都会把同一个 id 塞进 lastInsertId()，两条路径拿到一致的值，正好当幂等入口的返回值用。

(biz_type, biz_id) 两列组合没问题，但 biz_type 建议用 tinyint/枚举而不是 varchar，联合索引体积能差好几倍。列顺序也固定死 biz_type 在前：按业务类型刷流水、做补偿正好命中前缀，但「某用户全部流水」这种查询得另外加索引，别指望它。

队列指标那块你的印象是对的——容量监控的每日快照就是帖子/用户/附件/数据库/磁盘加慢查询 TOP，队列长度、pending、死信都不在里面，要盯只能自己在 Cron::register 里挂。但这类采样任务同样受懒触发影响，低流量站半夜不采样，曲线就是断的，跟开奖任务一样配 crontab 每分钟打 /cron 才稳。另外 XPENDING 只取 summary（count/min-id/max-id）就够，别一把拉全量 pending 明细，几千条 pending 时那个命令扫起来能把 Redis 卡住。

最后补一句：死信队列自己也要设上限和裁剪，只进不出照样顶内存；重放完记得把死信那条真删掉（ack + del 或 lrem），别只改状态。审计日志表主要是核心那套后台操作在写，你自己挂的重放入口得手动插一条记录，不会自动留痕。

两位表这个改法对，而且比“补几个角度”更重要的是翻转位——autoOrientImage() 内部就是按 EXIF 规范把整个变换做完，GD 手写才需要自己拆。

顺序上有一点要注意：2/4/5/7 不是随便挑一个顺序就行。5 是转置（沿主对角线镜像），7 是反转置，翻转和旋转交换顺序结果不一样。建议统一成先 flip 后 rotate，别按 case 各写各的。

透明背景那条我再进一步：只对源图 imagesavealpha 不够，imagerotate 返回的是新资源，alpha 状态不保证继承。更稳妥的做法是别用它的填充参数，先 imagecreatetruecolor、imagefill 透明色，再 imagecopy 旋转后的图。还有一个前置条件：imagecreatefrompng 对调色板 PNG 返回的是 palette 图，此时 imagesavealpha 无效，要先 imagepalettetotruecolor。

imagesx/imagesy 重取完全同意，建议封装成 rotate() 直接返回 [resource, w, h] 三元组，避免调用方沿用旧变量。代码看起来没错的时候，更容易出错。

内存那条补一句：memory_limit 要单独大于单请求峰值，否则不是排队，而是直接 fatal 500。另外 exif_read_data($f, 'IFD0') 只读第一个 IFD，能省不少解析开销，批量补缩略图时很划算。

【结论】三条我都认，其中 shellDepth 这条最有价值：它比断裂率更早暴露问题；但具体实现时有几个地方容易写错。

【展开】拆壳循环：不用 IdentityHashMap 或 Set 也行，深度上限既然是 10，直接开个 Object[10] 线性 == 扫描就够，零分配。用集合反而要担心强引用把异常对象和整条 cause 链挂到 handler 结束才释放；业务代码把整个请求体塞进异常 message 的情况真不少。另外 shellDepth 建议打直方图，或者只统计「≥3 层的计数占比」，别算平均值——正常集中在 0-2，均值会把长尾抹平，跟你说的「更早发信号」正好背道而驰。Error 单开基线同意，补一句：e.getClass().getName() 返回常量池字符串、不分配，用它当 label 比拼 message 安全得多。

分母两条曲线：前提是两个指标来自同一埋点源（同一个 filter 里同时累加 5xx 和总请求数）。如果总量取 access log、断裂数取 handler，口径和时钟都对不齐，两条曲线放一起反而更容易误判。

outbox：READ COMMITTED + 认领即提交完全同意，再补两个实际踩过的坑：① 抢占式 UPDATE ... LIMIT 100 拿不到「我到底认领了哪 100 行」，得先生成 batch_id 写进去，再 SELECT WHERE batch_id=? 查回来，顺便把回收定位也解决了；② attempts 的 +1 要放在认领时而不是失败回写时，否则消费者处理到一半进程崩了，这次尝试不会被计数，毒消息会无限重试。

【结尾】回收单独低频 Cron 赞同，建议顺手加个告警：回收条数突增基本等于消费者在批量崩溃，比盯积压量更早发现。

【结论】用类型系统把 release 兜住，比写十条编码规范都管用；再补一步——把「谁的许可」也编码进 Permit，跨线程误释放这条路才算真堵上。

【展开】给 Permit 加一个 owner 字段和一次幂等保护，十来行改动：

static final class Permit implements AutoCloseable {
    private final Semaphore s;
    private final Thread owner = Thread.currentThread();
    private final AtomicBoolean closed = new AtomicBoolean();
    public void close() {
        if (closed.compareAndSet(false, true)) {
            if (owner != Thread.currentThread()) throw new IllegalStateException("许可跨线程归还");
            s.release();
        }
    }
}

closed 用来防止有人绕过 try-with-resources 手动 close 两次，再次造成许可虚增；owner 校验在开发态开启（用 static final 开关控制），生产若要跨线程移交，再加显式 transferTo()，让「跨线程」变成需要写出来的动作，而不是顺手就发生。

另外两点边界。第一，try-with-resources 的资源表达式先求值，acquire() 抛 InterruptedException 时不会进 try 块、也就不会误 release，这点正合预期；但一次拿多个许可的 acquire(n) 叠加超时/中断，以及异步回调那种「拿和还不在同一栈帧」的场景，它救不了，后者只能退回 AtomicBoolean 一次性 settle。第二，close() 里别做打日志、写文件这类可能抛异常的事，close 抛异常会走 suppressed 机制，把业务主异常掩盖掉，只留计数和指标上报即可。

【结尾】再提醒一句：封装里若顺手用 acquireUninterruptibly()，中断标志会留着但调用方毫无感知，最好同时提供带超时重载，把拒绝次数打成指标——配合 getQueueLength() 才有诊断价值。

这两条我都认，但**扩容和 CallerRuns 各自都得补一个上限约束，否则它们会从解决方案变成新的故障源**。

扩容那条，关键是必须和 maxFrameLength 联动：无上限翻倍的累积缓冲区等于给对端留了一个内存耗尽的入口，只要发一个声明了超长长度的头，就能把连接缓冲区撑爆。所以扩容到上限就直接抛 TooLongFrameException 断连，和 Netty 侧语义对齐，别搞出两套。另外起点别设成 0，给个 1KB 左右的下限，避免小包场景频繁复制；remaining() >= 4 那个判断建议单独抽成 peekLength()，只在够的时候调用，逻辑集中也少一处漏判。

CallerRunsPolicy 我保留一半：它的代价是把队头阻塞从线程池搬回 IO 线程，单 selector 线程上跑一个长任务，所有连接的 accept/read 延迟都会一起被拖住。所以我只对「短、幂等、无阻塞 IO」的任务用它；长任务配小有界队列，超限直接断连——这种客户端本来就该被打掉，比让它挤在队列里更干脆。

「本轮只改标记、下轮改 interestOps」这个我完全同意，只提醒一句：单 selector 线程直接改没问题，但一旦业务线程也调 write，标记队列的入队和消费就得线程安全，Netty 那里用的是 MPSC 队列，手写最容易漏锁。

leakDetection.level 还得多写一行：它必须在 Netty 类加载前通过 -D 设置，运行时 System.setProperty 不生效。回滚脚本里除了关掉 paranoid，记得连 -Dio.netty.leakDetection.targetRecords 一起清，否则默认只记一条引用链，泄漏点定位不到。

三条补充我都同意，尤其是 cache() 必须包在函数定义上——写成 cache(fn)(id) 基本会引发这个 bug。

预签名 URL 那个，比你说的还多一层缓存要计算：客户端的 Router Cache。 Full Route Cache 只影响静态路由，而 Payload 到了浏览器后还会被 Router Cache 存一段时间（Next 14 默认 30s，15 对动态页才降到 0）。所以 TTL 要比 revalidate 加上这段过期时间再长一截，才安全。更彻底的做法是根本不让签名进 payload：只传对象 key 或公开 ID，客户端真正需要下载时，通过 Server Action 现场签名再取，一次性链接天然不受缓存影响。另外判断路由到底有没有被静态化，看 build 输出里那条路由标的是 ○ 还是 ƒ 比猜更可靠，调用了 cookies()、headers()、noStore() 都会自动转成动态。

cache() 还有一个放大效应值得配上： 你提到的 generateMetadata 和 page 并行执行，如果只在 page 里包了 cache()，metadata 那边照样会查一次数据库，去重等于没做。稳妥的写法是在数据层统一包好，页面里只 import 那个已经包好的引用，别在调用处临时包。

globalThis 那段我完全同意， 标准写法是 const prisma = globalThis.__prisma ?? new PrismaClient()，再在非生产环境赋值回去。补一句：只挂连接池和 ORM client 就够了，别把业务单例也挂上去，否则热更新时残留的旧实例会拿到过期配置，变得更难排查。

toDTO() 那条纪律里有个例外要留意： Date 能顺利通过边界，但如果客户端拿它做本地化格式化，服务端渲染和客户端水合时的时区不同就会造成 hydration mismatch。这类值建议在 toDTO 里直接转成 ISO 字符串或时间戳，把「跨边界只传原始类型」执行得更彻底。

最后同意的：window 检查放 effect 里是对的，模块顶层只留 typeof window === 'undefined' 这种纯判断，不要有取值逻辑。