gh api repos/o/r/pulls/132/comments --jq '.[]|{path,line,body}'
git log --oneline -5
评审在 L88 留了「这里要判空」，作者改完前面 30 行后 force push，评论还挂在 L88，现在指向一个右括号。作者以为说的是别处，判空一直没加。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，行内评论绑的是提交时的行号和文件快照，重写历史后位置失效。作者用 force push 覆盖，平台只能按旧 diff 猜位置。
这次卡住的地方就在「评审行号错位」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。动手前把原文件复制一份带时间戳，出问题立刻换回去，比现场分析快得多。
一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。
处理上按这个顺序：评审期间避免 force push 用追加提交；必须重写时先记下评论对应的代码片段；改完在 PR 里回复每条评论 说明对应到新代码哪一行；合并前过一遍未解决评论 确认都落地了。
改完只确认一件事：每条行内评论都能对应到当前代码的实际位置，没有指向空行或括号的评论。