不上传歌词，也能做可靠的 LRC 时间轴检查：纯前端工具的边界与验收

婚礼播放、K 歌制作和视频字幕对轨有一个共同风险：歌词文件平时看起来正常，真正播放时才发现时间轴回跳、重复，或者整首歌整体偏移。为了在现场使用前发现问题，我做了一个纯前端的 LRC 歌词检查台。它不需要后端，歌词也不会离开浏览器。

为什么选择纯前端

歌词可能包含尚未公开的内容，也可能只是用户不愿上传的私人文件。工具使用浏览器的 FileReader 本地读取文件，检查结束后用 Blob 生成文本报告。实现不调用 fetch、XHR 或 WebSocket，也不使用 Cookie、localStorage 和 IndexedDB。关闭页面后，输入内容不会被应用保存。

纯前端还有一个实际好处：工具可以作为静态文件离线运行。婚礼现场网络不稳定时，打开本地 HTML 也能完成检查。对这种小工具来说，少一个后端就少一类部署、鉴权和数据留存问题。

解析和检查分开

实现中最重要的决定，是把“读懂 LRC”和“判断是否有问题”分成两个纯模块。

解析器负责：

• 识别一行中的一个或多个时间戳；
• 读取标题、歌手和 offset 等元数据；
• 保留原始行号，便于准确定位；
• 兼容 UTF-8 BOM 和 CRLF 换行。

检查器只接收解析后的结构化结果，检查秒数范围、时间乱序、同行乱序、重复时间、重复或非法 offset，以及有文字却缺少时间戳的行。这样，核心逻辑不依赖 DOM，可以直接在 Node.js 中运行测试。

三个容易被忽略的边界

1. 不能只比较每行的第一个时间戳

同一行可能包含多个时间戳。正确做法是先验证行内顺序，再比较相邻行边界，否则一行内部的回跳会被漏掉。

2. 拒绝新文件时必须清除旧报告

如果用户先检查了合法文件，随后选择一个超出大小限制或编码异常的文件，界面必须立即清除旧结果和下载按钮。否则用户可能误把旧报告当成新文件的检查结果。这个问题不显眼，却会直接影响现场使用的信任度。

3. 错误信息要带原始行号

解析时过滤空行虽然方便，但会让结果中的行号与源文件不一致。保留原始位置，用户才能快速回到歌词文件定位问题。

验收比“能运行”更重要

当前核心模块用 62 项断言覆盖正常歌词、多时间戳、BOM、CRLF、非法秒数、重复时间、时间回跳、offset 和报告生成等场景。浏览器侧还验证了中文输入、文件大小限制、报告下载，以及编辑内容后旧结果自动失效。

这里的测试重点不是追求一个漂亮的覆盖率数字，而是覆盖真实使用中最容易误判的边界：输入被拒绝后状态是否清空、原始行号是否准确、同一行多个时间戳是否完整检查。

适用范围和限制

这个项目不试图成为播放器，也不负责自动修复歌词。它专注于播放前的质量检查：告诉用户哪里可能有问题，并给出可定位的行号和报告。真正播放前仍应在目标设备上抽查几首歌，尤其是包含大量重复时间戳或特殊 offset 的文件。

功能越聚焦，离线工具越容易审查，也越容易在真正重要的场合保持可靠。

后续计划

下一步可以继续补充编码识别、更多元数据校验和可重复的浏览器端验收，但仍保持三个边界：不上传歌词、不引入不必要依赖、不把未验证的结果标记为通过。