PR 上有 17 条未解决评论，作者改了 4 条，其余回复「后续优化」，审批人点了通过。合并后其中一条关于分页参数的评论对应的 bug 在线上复现。日志里能对上时间点，这种反而好排。
平台不强制解决评论才能合并，未解决状态只是个标记。评审人点了通过就等于放弃追。这一点先确认清楚，后面就不用反复试。
gh api repos/o/r/pulls/141/comments --jq '[.[]|select(.in_reply_to_id==null)] | length' gh pr view 141 --json reviewDecision
「评审意见未闭环」改完先别急着全量，挑一台机器放半天，真有问题这段时间就能看出来。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。权限不要一口气开到最大，先加到够用再往上试，范围小才好收。
处理上按这个顺序：开启合并前必须解决所有评论的规则；确实不打算改的 由评审人显式标记为 wontfix 并写明原因；把后续优化转成 issue 关联到 PR；每周看一次未闭环评论的数量。
结果对不对很好判断，合并时未解决评论为 0，每条 wontfix 都有对应 issue 编号。