LRC 歌词校验：时间标签都合法，为什么播放还是错位？

做离线 LRC 歌词检查器时，一个容易忽略的问题是：每一行都能匹配时间标签，整首歌词却未必能正确播放。词条重复、时间乱序和全局偏移，属于不同层次的问题，不能用一条正则表达式一起判断。

先把三个时间分开

以 [00:02.50]灯光亮起 为例，标签本身表示 2500 毫秒。文件中的 [offset:200] 则是独立的全局偏移信息。检查器至少应保留原始时间、offset 和行号，避免一上来就改写歌词。不同播放器对 offset 的支持可能不同，检查报告应该展示偏移值，并提醒使用者在目标播放器确认效果。

分钟可以超过两位，但秒数必须小于 60。小数部分按十进制秒解析：.5 是 500 毫秒，.50 也是 500 毫秒，.005 才是 5 毫秒。直接把小数部分转整数，会产生十倍甚至百倍误差。

合法不代表顺序正确

下面三行分别符合时间格式，却包含两类问题：

[offset:200]
[00:02.00]灯光亮起
[00:01.50]序幕开始
[00:02.00]掌声响起

第二个时间早于前一个时间，需要报告乱序；第三个时间与第一个重复，需要报告对应行号。但是，重复时间也可能是合唱或翻译歌词的有意安排。因此检查器应该提示核对，不能替使用者直接删除。

一行还可能包含多个时间标签，例如同一句副歌对应两个时间。只取第一个匹配会漏检，应逐个展开标签，同时保留它们所属的原始行号。

把解析与界面分离

解析函数只接收文本，返回时间戳数量、offset 和问题列表。它不访问文件系统、不下载歌曲，也不负责修改页面。界面层再决定如何显示报告。这样既能在网页中运行，也便于在命令行复用相同逻辑。

错误信息要能定位，例如“第 4 行：时间与第 2 行重复”，比笼统的“歌词格式错误”有用。没有时间标签、秒数超过范围、offset 不是整数、重复 offset、数值超过安全整数范围，也应分别说明。

文件输入还有两道边界

第一道是体积。读取前检查文件大小，粘贴文本后再检查文本字节数。字符数不等于字节数，中文尤其不能直接用字符串长度估算文件体积。对于简单的歌词工具，设置合理上限可以避免页面被异常大文件拖慢。

第二道是编码。可以先严格尝试 UTF-8，再对确实需要支持的旧编码做明确处理，并在界面标出识别结果。不要静默吞掉乱码，再生成一份看似正常的报告。

验收要覆盖状态变化

至少检查四种操作：加载示例后能定位乱序和重复；修改文本后旧报告立即失效；重新检查后允许导出；清空后不再导出旧内容。只有首次点击成功，还不能说明整个流程可靠。

网页美化也应保留这些行为。比如把状态栏改成“圆点＋文字”后，如果仍对父元素写 textContent，就会把圆点结构一起清空。应该更新专用文字节点，再切换状态属性。

这个小工具给我的提醒是：解析正确、交互正确、导出正确，是三项独立验收。把它们分别验证，比只看页面是否漂亮更能减少现场播放时的意外。

本文为 AI 辅助整理的技术实践笔记，示例歌词为测试文本，不含真实歌曲内容或私人环境信息。