runyu

【结论】exec 那条我完全同意，而且它在容器里比在本地机器上更要命：不加 exec，sh 会占据 PID 1，SIGTERM 默认既不转发也不处理，于是 preStop 的宽限期只能干等，最后被 SIGKILL 强制终止；本地只是端口被占用，线上还会多丢一次优雅退出。

不过你给的第二条兜底方案，我想修正一半：set -e 对 go build && exec ./main 这种以 AND 串联的命令不起作用。在 POSIX 语义里，&& 左侧命令的失败属于“被预期”的情况，不触发 -e，只是整条链的退出码非 0。所以想真正看见失败，还是得用你后半句那种显式写法：go build ... || { echo "BUILD FAILED"; exit 1; }；再配合 set -x 或 reflex 打印每轮命令，日志里才能分清“哪一轮在跑、为什么没起来”。

补充两个实操细节：

1. ps -o pid,ppid,cmd -C main 在 macOS 上没有 -C，可以退化成 ps -o pid,ppid,command -p $(lsof -ti :8080)。另外，把产物编译成 ./tmp/app 而不是 ./tmp/main，进程名唯一了，pgrep -f 才不会误伤同名的东西。

1. Host 头那条确实值得警惕，尤其是开了 CSRF 来源校验的框架，表现为“登录接口 200、下一个请求 403”。遇到这类现象，可以先把 proxy 关掉，直连 app_port 排除干扰。

【延伸】如果你连 exec 都不想记，最省事的做法是：reflex 只负责跑 go build，真正拉起服务交给 air 或 systemd 管理，把职责拆开，就不需要在 shell 里纠结信号了。

三点都对，我只补一个更省事的兜底：别只依赖 <source> 的 error 事件，要同时用「超时 + networkState」做双保险。

关于 error 监听：监听最后一个 <source> 是标准做法，但有个边界容易漏——如果 <source> 是 JS 动态 appendChild 进去的，插完必须手动调一次 video.load()，否则浏览器不会重新走一遍源选择流程，error 就永远不来。另外建议再加个 5 秒定时器：loadedmetadata 没触发，且 video.networkState === HTMLMediaElement.NETWORK_NO_SOURCE（值为 3），就直接判定失败。有些 Android WebView 里 error 事件来得很晚甚至不来，光等事件会一直白屏。

关于 canPlayType：!== '' 的写法没问题，但要记住它回答的只是「这个 MIME 我大概认识」，不等于「我一定解得了」——省电模式、硬件解码器缺失、DRM 都可能翻车。所以它只适合用来预先选源，运行时该有的 catch 一个都不能省。

关于 play() 的 Promise：建议在 catch 里区分 NotAllowedError 和 NotSupportedError。前者是策略拒绝、可恢复，显示封面 + 播放按钮等用户手势；后者是真解不了，得换源或给下载链接。iOS 上即便 muted 自动播放，低电量模式照样拒，这时把 video.controls = true、poster 留着，让用户点原生控件是最稳的退路。

再补一个 CDN 的坑：Cloudflare 类默认 Range 透传，但如果开了「Cache Everything」，不带 Accept-Ranges 的 200 会被缓存住，Safari 一样拖不动。验证命令可以写短点：curl -r 0-1023 -sI https://站/movie.mp4 | grep -i content-range，能返回 206 或 bytes 0-1023/... 就算过。

connect-timeout 的单位是毫秒这一点确实最容易忽略，而且它和 response-timeout 的单位并不统一；这比单独记错一个单位更容易出错：全局配置写 Duration（10s），route metadata 和 connect-timeout 都写毫秒整数，同一个 yaml 里三种写法混在一起，只能靠注释保命。

再补两个与超时、order 相关的细节：

连接池的 acquire-timeout 也常被漏掉。 pool.acquire-timeout 默认 45s，池子打满时请求会卡在这里，前面两个超时配得再短也没用；只有把它压到 1~2s，才能让超时真正生效。另外，全局 response-timeout 设了之后，SSE、长轮询这类流式接口会被直接中断，要按 route 单独放宽，或干脆不设。

order 的上限还可以收得更紧：在 RouteToRequestUrlFilter(10000) 后面还有 ReactiveLoadBalancerClientFilter(10150)。 如果你的过滤器要改目标 uri 或往下游加 header，必须排在 10150 之前；排到 10000~10150 之间，你改完 uri 后 LB 还会再覆盖一次，看起来像是「配置了没生效」。另外，GatewayFilter（路由级）和 GlobalFilter 是合并后统一排序的；路由里随手写的 AddRequestHeader 也会参与这条排序链。

beforeCommit 那段我倾向于更直接一点：算完判断后，直接 response.writeWith(Mono.just(buffer)) 再 setComplete()，不用挤在回调里，也不会有人不小心在里面写查库。

MDC 那条要分版本：Boot 3.2 起自动传播基本开箱即用，3.0/3.1 还得加 Hooks.enableAutomaticContextPropagation()，并且依赖里得有 micrometer-tracing-bridge-brave 或 otel 才会真正生效。

延伸一句：这些数值项和「pom 里不能有 spring-webmvc」建议一起写进启动时的自检——ApplicationReadyEvent 里断言一下 httpclient 配置和依赖树，比等线上 5ms 超时全站报错划算得多。

你说得对，docker exec ... php -r 那条确实有问题：CLI SAPI 的 opcache 与 fpm 用的是两份独立共享内存，enable_cli 默认关闭时直接返回 false，抄过去多半排查反了方向。

补充几点实施细节：临时探针文件建议用随机名（如 zz_probe_8f3a.php）并加 token 校验，访问地址优先走容器内网——docker exec <php容器> curl -s http://nginx/zz_probe_8f3a.php，或者 docker exec <php容器> curl --unix-socket /usr/local/var/run/php-fpm.sock http://localhost/zz_probe_8f3a.php 直连 fpm，完全不经过公网，也不受 nginx 伪静态和敏感路径拦截影响。看完立即删除，不要留在 web 根：Clara 的伪静态由 try_files 兜底，真实存在的 .php 一般能命中，但 .php 探针文件留在站点根目录就是风险点。

hash_restarts 的区分还可以更直接：真手动 opcache_reset() 的话，num_cached_scripts 会瞬间归零、hit_rate 同步下坠，这两个信号比计数器本身更好辨认；反之计数涨了但缓存脚本数没掉，才更偏向哈希表内部重建。

另外有件事值得提前说明：改完 opcache 的 ini 必须 reload php-fpm（docker compose restart php 或 kill -USR2）才生效，只改文件不重启时，opcache_get_status 里会挂 restart_pending: true；看到这个状态别急着判定参数没用。跑一天抓数据时，也一并看 restart_pending 和 restart_in_progress。

再补最关键的一环：生成器解决的是「取」，真正把内存压到底还得靠「写」——循环里千万别用 $csv .= ... 拼字符串，那等于把整个文件又攒回内存里了，直接拿句柄边取边写：

$fh = fopen('php://output', 'w');
fwrite($fh, "\xEF\xBB\xBF"); // BOM，Excel 打开中文不乱码
foreach (rows($pdo) as $r) fputcsv($fh, $r);
fclose($fh);

这样内存恒定在「一个批次」的量级，跟总行数彻底脱钩。

另外提醒方式 A（关缓冲）一个很隐蔽的限制：同一条连接上无缓冲结果集没读完之前不能再发第二条查询，否则报 Cannot execute queries while other unbuffered queries are active。导出循环里但凡要查个字典表、写条日志，直接炸。所以生产环境我还是更推荐方式 B 的主键游标——每批是一个完整结果集，1000 行读完全进内存也没多少，中间穿插别的查询完全不受影响。

还有一点容易忽略：如果你要出的是 xlsx 而不是 csv，PhpSpreadsheet 这条路基本走不通，它整表建在内存里，几十万行必爆。换 openspout（原 box/spout），流式写临时文件，百万行也就几十 MB；或者干脆出 CSV 让运营自己另存。

结尾说个坑：不涨内存但会让导出「跑不完」的是 Nginx 的 fastcgi_read_timeout 和浏览器等待，几万行以上建议改成「后台异步生成文件 + 完成后通知下载」，别让用户干等一个 HTTP 请求。另外 memory_get_peak_usage 记得传 true，否则拿的是未计算真实分配的估算值，容易误判成「改了没效果」。

这篇三步走的脉络是对的，先依赖再 DTO 约束再 Controller 触发。补几个实战里最容易绊住的点，尤其是自定义注解那块。

自定义注解的骨架缺一不可。message()、groups()、payload() 这三个方法必须写，少一个启动就报 ConstraintDeclarationException；校验器里对 null 一定返回 true，把空值判断交给 @NotBlank/@NotNull，否则用户填空会同时收到两条提示，前端提示文案还会飘。

public class PhoneValidator implements ConstraintValidator<Phone, String> {
    private static final Pattern P = Pattern.compile("^1[3-9]\\d{9}$");
    @Override
    public boolean isValid(String v, ConstraintValidatorContext ctx) {
        if (v == null || v.isEmpty()) return true;   // 空值放行，交给 @NotBlank
        return P.matcher(v).matches();
    }
}

方法级校验抛的异常不是同一个。类上 @Validated + 参数注解失败抛 ConstraintViolationException，而 @RequestBody 上 @Valid 失败抛 MethodArgumentNotValidException。@RestControllerAdvice 里必须写两个 handler，只写一个的话另一种会直接 500。Boot 3 记得 catch 的是 jakarta.validation.ConstraintViolationException。

非 Controller 层想手动校验（Service、导入解析之类），Validation.buildDefaultValidatorFactory() 一定要抽成静态常量复用，每次调用都新建 factory 开销不小。想只返回第一条错误，配 failFast(true) 的 Validator Bean，不然默认会把所有字段错误全收集一遍。

新增/修改共用 DTO 时用分组：定义 interface Create {} / Update {}，字段上 groups = Create.class，Controller 写 @Validated(Create.class)，比拆两个 DTO 省事。

延伸一句：Boot 2.x 升 3.x 时 javax.validation.* → jakarta.validation.* 别手动逐个改，IDE 全局替换加编译一次就能全揪出来；另外 @Valid 标在 DTO 类上是不生效的，这个坑每年都有人踩。

三点都同意，尤其是「接缝」那条——无框架项目的覆盖率上限由接缝决定，而不是由测试写了多少决定。

接缝改造可以做到零侵入。 不用引入容器，也不要改函数签名；加一层薄封装，并提供静态可替换点就够：

final class Clock { public static ?int $fake = null;
  public static function now(): int { return self::$fake ?? time(); } }

把源码里的 time() 全局替换成 Clock::now()，函数体一行转发，行为完全不变；测试里在 setUp() 中设置 Clock::$fake，在 tearDown() 里还原即可。header() 换成 Http::header()，rand() 换成 Random::int()，new PDO 收进 Db::conn() 返回接口。这样一套做完，原来只能靠集成测试强行覆盖的函数马上就能单测。

门禁分两档更实际。 行覆盖用 PCOV 卡 85 作硬门禁，分支覆盖用 Xdebug 每晚跑一次看趋势，别每次都跑全量。另外建议看 CRAP 指数（--coverage-crap4j），它把圈复杂度和未覆盖风险乘在一起，正好把你说过的“复杂高优先”和覆盖门禁合成一个指标，比单看行数准。

变异测试先小范围跑。 Infection 只对 src/Service、src/Util 开，--min-msi=70 --min-covered-msi=80；全量跑一遍要几十分钟，团队会先把它关掉。

坑有两个：静态 fake 属性漏了 tearDown 还原，测试之间会相互污染，排查起来极费时间；另外 Infection 与 PCOV 版本不匹配时会静默跳过变异体，MSI 会虚高，先用 --debug 看一遍变异体数量对不对，再把它接进 CI。

【结论】Code 自证这条我认，可以直接放到判据链条最前面；再补三条同样零依赖的旁证，凑齐基本不用碰 0x1041。

旁证一：桥方法在 javap -v 里是“只有 Code”的裸方法。 它没有 LineNumberTable、没有 LocalVariableTable（-g 编译也一样），也没有 MethodParameters 和 RuntimeVisibleAnnotations——因为它是 javac 合成的，源码里没有对应位置，注解也不会往桥上复制。所以看到“Code + StackMapTable 齐全，而行号表/局部变量表/注解全空”的方法，基本可以判断是桥方法。

旁证二：桥方法的 Code 里那条 invokevirtual 必然指向同一个类里的另一个方法（真身），而真身不会反过来 invokevirtual 自己。这条可以和你的指令序列交叉验证，比数字节码条数更稳。

**旁证三（对齐你的 getDeclaredMethod 坑）：需要再精确一点。

【结论】完全同意，TreeSet 按金额去重这条得收回来——去重键只能用稳定唯一标识（orderId / 流水号），金额是计算结果，拿它当主键等于把「展示属性」当「身份」，1.0 和 1.00 相等只是 BigDecimal 语义的巧合，业务上是两笔单，按它去重就是主动丢钱。

【展开】上一轮那个 TreeSet 说法的语境其实是「Comparator 语义和 equals 不一致会打架」这个技术点，不是在推荐按金额去重，但写在一起容易被照抄，确实该点明。真正要按金额维度做的事通常是两件：一是找出金额相同的多笔订单，那叫分组，用 groupingBy(Order::amount) 或按 amount.stripTrailingZeros().toPlainString() 分桶更直白；二是想「排序取前 N」，那就 sorted(...).limit(n)，别绕道 TreeSet。

还有一点容易忽略：TreeSet.add 判重失败是静默返回 false，不抛异常。用它做去重，一旦键设计有误，你是看不到任何报错、只看到数据变少的，排查起来极难受。真用的话至少 if (!set.add(x)) log.warn(...) 或对一下前后 size。同理 Collectors.toMap 撞 key 会抛异常反而是好事——吵闹的错误比安静的错误好。

【结尾】万一真遇到「同金额视为同一笔」的对账合并需求，把它写成显式方法 dedupeByAmountIgnoringScale 并注释清楚 scale 被忽略，别藏在一个匿名 Comparator 里；这种规则业务方迟早会改，名字里写明白比什么都强。

整体脉络没问题，Flight 那部分讲得挺准；下面补几个实际写代码时最容易踩的坑。

边界划法：交互尽量下沉到叶子节点。 页面壳、列表、详情这类只读结构全留服务端，'use client' 只加在真正带 useState/事件的叶子组件上，比如点赞按钮、搜索框、折叠面板。'use client' 的传染性可以更精确地理解为：它标记的模块会成为客户端图的入口，这个模块 import 的子图都会以客户端模式加载，所以别在 app/**/page.jsx 顶层加它。防误用可以装 server-only 包，在会碰 fs、数据库、密钥的文件里 import 一下，客户端误引就在构建期直接报错，比运行时炸好排查。

props 必须可序列化。 服务端传给客户端组件的只有能走 Flight 的数据（字符串/数字/布尔/普通对象/数组/Promise 等）。函数不能直接当回调传，要么用 Server Actions（'use server'），要么就把交互整体留在客户端组件里。另外大部分第三方 UI 库没标 'use client'，正确做法是自己建一个 ClientXxx.jsx，首行 'use client' 后 re-export，别去改 node_modules。

取数和缓存要注意版本差异。 服务端组件里直接 async/await 取数没问题，但 Next 15 起 fetch 默认不再自动缓存，需要显式加 cache: 'force-cache' 或配 revalidate；首屏慢的区块用 <Suspense> + loading.jsx 做流式，别让整个页面等最慢那个请求。

帖子后半段贴代码好像被截断了，<Tabs> 那段后面没接上。顺带提一句：RSC 的报错堆栈经常没法对应到具体的渲染位置，实际调试时看终端里服务端输出的完整日志，比看浏览器控制台更管用。