项目快上线了，验收测试报告一出来，满屏红字——‘待修复’‘延期处理’‘需确认’。这时候开发最怕的不是写新功能，而是翻出那堆被标记为‘遗留’的问题单，一边看一边叹气：这到底是该修，还是该推？
遗留问题不等于甩手掌柜
很多团队把‘遗留’当成缓兵之计：‘先上线，后面再补’。结果呢？客户反馈的截图发到群里，才发现那个‘低优先级’的按钮错位，导致支付流程卡在第三步；那个‘UI微调’的弹窗延迟，实际影响了扫码识别的成功率。遗留问题不是存档，是悬在上线头上的小锤子——轻则返工改bug，重则召回版本。
怎么筛，才算真‘可遗留’？
判断一个验收问题能不能留，得过三关：
- 用户是否感知：比如后台日志多打了一行warning，前端完全无感，且不影响任何业务逻辑，这类可以记入技术台账，但不阻塞上线；
- 是否有规避路径：例如导出Excel功能在IE11下失败，但团队已明确只支持Chrome/Firefox，且用户端已提示浏览器要求，这种属于合规范围内的‘可接受偏差’；
- 修复成本与风险比：改一行JS能解决的样式抖动，别拖；但为修复某个老框架里嵌套五层的异步状态，要重写整个模块——这时候该做的是记录+监控+排期，而不是硬上。
落地建议：用工具管住‘遗留’
别靠Excel或微信截图记遗留项。在Jira或Tapd里建专属‘Acceptance Backlog’看板，字段至少包含：原始场景描述、复现路径、当前影响面（用户/模块/频次）、临时方案（如有）、承诺解决Sprint。每次迭代评审会前，第一件事就是同步这张表的进展。
示例：某电商后台订单导出功能，在验收时发现导出CSV中文乱码，仅影响运营侧手动导出（非API调用），已有临时方案（复制到记事本另存为UTF-8）。标记为‘遗留’，排入下个迭代，同时在导出按钮旁加了小提示：‘推荐使用Chrome浏览器以获得最佳导出体验’。
<button class="export-btn" title="推荐使用Chrome浏览器以获得最佳导出体验">导出CSV</button>真正靠谱的遗留处理，不是‘先放着’，而是‘看得见、说得清、有人盯’。上线前最后一小时，盯着的不该是倒计时，而是这张没闭合的遗留清单。