我的标题宽度守卫通过了所有测试。它测量的却是渲染器从未绘制的文本。
关于字幕分段不佳的用户投诉引发了一次 bug 修复,却引入了一个新的、细微的问题。原始问题是字幕被分割为固定长度的单词块,而忽略了句子结构,导致出现不合逻辑的断行,例如在句子中间强行截断。修复方案实施了更优的分段规则,包括尊重标点符号并针对每个块设定目标词数。关键改进是增加了渲染块的像素宽度上限,以确保其能适配屏幕。该宽度上限本意是测量实际渲染文本的宽度。然而,测量文本宽度的代码在测量前错误地将文本转换为全大写。这是由于借用了视频管线中另一部分刻意使用全大写以达成视觉风格的步骤。在所选字体中,全大写文本的宽度大于混合大小写文本。测量结果对全大写输入是准确的,但实际字幕仍以原始混合大小写渲染。这种差异导致宽度守卫误判文本宽度远大于实际值,从而强制进行不必要的分割,生成了单字块,用户体验甚至劣于初始问题。关键在于,所有自动化测试均通过,因为宽度测量函数对其接收到的输入(即全大写文本)运行正确。测试并未验证测量文本与实际渲染到屏幕上的文本是否一致。该 bug 仅由人工观看渲染后的视频时发现。此情况凸显了一个常见陷阱:生产环境与验证环境存在独立的代码路径,本应在文本变换等假设上保持一致。当这些假设发生漂移时,便会涌现出自动化测试无法捕捉的细微 bug。作者建议将变换函数在两条路径间共享,或定期采样并检查实际渲染输出,作为缓解策略。若仅依赖绿色的测试套件而缺乏人工监督,此类细微差异便可能持续存在而未被察觉。