163MusicLyrics 终极指南：网易云、QQ音乐歌词批量提取，LRC/SRT 一次配齐
【免费下载链接】163MusicLyrics云音乐歌词获取处理工具【网易云、QQ音乐】项目地址: https://gitcode.com/GitHub_Trending/16/163MusicLyrics
本地几百首 MP3 缺歌词？一首首去网页上复制再手改时间戳，一天都忙不完。163MusicLyrics 是一款覆盖网易云与 QQ 音乐的免费歌词提取工具，跑在 Windows、macOS、Linux 三大平台：输入歌曲 ID、专辑链接或关键词，直接产出带时间轴的 LRC / SRT 文件，单曲、专辑、整库目录全场景支持。
极速部署与初见体验 ⚡
不想折腾环境的话，项目 Release 里直接提供了五个平台目标的打包产物（win-x86、win-x64、linux-x64、osx-x64、osx-arm64），全部是自包含单文件，下载解压即用，机器上连 .NET 运行时都不用装。
自己动手编译也只要三条命令，前提是装好 .NET 9.0 SDK：
git clone https://gitcode.com/GitHub_Trending/16/163MusicLyrics cd 163MusicLyrics/cross-platform dotnet build MusicLyricApp.sln && dotnet run --project MusicLyricApp技术栈一句话带过：C# 编写，目标框架 net9.0，界面基于 Avalonia 11.3.0，MVVM 架构配 CommunityToolkit.Mvvm 做绑定——所以 Windows 上写好的同一套 UI 代码，在 macOS 和 Linux 上原样可跑，不需要维护多套界面。
启动后主界面就是一个搜索工作台：输入区在上，结果表格在下，来源、歌手、专辑、时长逐列摆开，选中哪首，右侧立刻出歌词预览。把一条网易云分享链接粘进搜索框点一下，就能验证它到底好不好用。🎯
核心工作流：从单首到批量 🎯
如何精准定位？ID、链接、专辑通吃
最常见的场景是手头有 MP3，想补一份官方歌词。把播放器里的分享链接整段粘进搜索框，工具会自动从中解析出歌曲 ID；也可以直接输 ID，用英文逗号分隔一次贴多个。
查询对象不止单曲——专辑 ID 和歌单 ID 同样受理，工具先把专辑/歌单展开成歌曲列表，再逐首取歌词。这条解析逻辑集中在 SearchService：输入先判断是不是一个已存在的目录，是则走目录扫描分支，否则按逗号切分成 ID 列表，再逐条识别它到底是单曲、专辑还是歌单。单个 ID、一串 ID、整个文件夹，最终汇入同一条代码路径。
只记得关键词怎么办？模糊搜索加双平台聚合
另一类场景是"只记得某歌手唱过一首日文歌，完整歌名都记不清"。输入关键词，工具调平台搜索接口，把命中结果放进一个选择窗口，你挑出对的那首即可。
打开聚合搜索后，同一次输入会同时查网易云和 QQ 音乐两边，哪边有结果就显示哪边——对只在单一平台上架的歌尤其有用。
选中歌曲后，输出可以继续做文章：
- LRC 直接进播放器，SRT 直接进字幕软件；
- 外语歌可在设置里填彩云小译或百度翻译的密钥，译文与原文按交错、合并、分文件三种排版任选组合输出；
- 中文歌可追加拼音行；
- QQ 音乐的逐字歌词（KTV 式逐词点亮）也能取，打开逐字模式后，预览里每个字都有独立时间戳。
如何批量扫描文件夹？整库歌词一次处理完
📂 如果你的文件已经按歌曲 ID 命名（批量整理音乐库的人常这么干），直接把目录路径贴进搜索框：工具遍历目录，把每个文件名去掉扩展名后当作候选 ID 校验，合法的进查询队列，不合法的自动跳过，无需提前写任何脚本。
结果进入批量管理界面，每首歌的状态单独可查：无歌词的、网络报错的各有计数，末尾一行"累计 N 成功 N 失败"收尾——失败清单直接就是重试清单。
批量保存管理窗口里勾选目标歌曲，统一指定输出格式（LRC/SRT）、排版方式和文件编码，一次保存整批，保存结果按成功/跳过分开列出。
网络慢或在内网？代理模式一次配好
所有网络请求统一经由 NetworkClientFactory 创建，默认 30 秒超时；代理支持直连、带认证的 HTTP 代理、跟随系统代理三种模式，内网环境下在设置里配一次即可全局生效。发版侧，publish.sh 一条命令跑完五个平台目标，Windows 打 zip、其余打 tar.gz，文件名自动带版本号。
为什么它快且准（底层逻辑通俗化）⚡
重复查询为什么秒回？两层缓存在挡子弹
批量跑一两千首歌，最怕的是同一首被反复打接口。这个项目用两层缓存解决：
第一层在内存。MusicCacheableApi 基类把所有公开方法写成同一个模板：先查GlobalCache，命中直接返回；没命中才调子类真正发请求的Xxx0方法，成功后写回缓存。核心就一行套路——
GlobalCache.Process(平台, 缓存类型, 歌曲Key, () => 真正发请求的方法)缓存 key 用"平台^ID"拼接，网易云和 QQ 音乐的同一首歌互不串扰。
第二层在磁盘。LocalSongCacheService 把每首歌的信息和歌词序列化成 JSON，按网易云_{songId}.json一首歌一个文件落盘，默认上限 128 MB，超出后从最旧的写入开始删。批量查询先查这层，命中就不再联网——所以一千首歌的歌单第二次跑，几乎全程是本地读文件的速度。而且缓存就是纯 JSON，用文本编辑器直接能看，排查"这首歌的歌词到底取了没有"不用写任何辅助脚本。
双语歌词时间戳对不齐？对齐逻辑分三步
拿过双语歌词的人都踩过这个坑：平台给的原文和译文时间戳经常差几十毫秒，偶尔还整行缺失。LyricUtils 里的对齐逻辑分三步：先按毫秒精确匹配；对不上的，在前后"匹配精度偏差"窗口内找最近的未匹配原文行，把译文时间戳修正过去；仍缺失的行，按配置的缺失规则留空或回填原文内容。
LRC 转 SRT 还有个隐藏细节：LRC 每行只有开始时间，SRT 却要"开始 → 结束"一对。SrtUtils.LrcToSrt用下一行的开始时间推导当前行的结束时间，末行延伸到歌曲总时长，乱序行和同一毫秒的多行都有专门分支处理。所以最终拿到的双语 LRC 不会"译文跑位"，SRT 丢进字幕软件就是可用状态。
开发者视角与项目布局 🔧
对想读源码或做二次扩展的读者，cross-platform/MusicLyricApp/的核心结构非常克制：
cross-platform/MusicLyricApp/ ├── Core/Service/ # 平台API（网易云/QQ）、翻译、存储、搜索、更新服务 ├── Core/Utils/ # 歌词解析、LRC转SRT、渲染、拼音等纯函数工具 ├── Models/ # 数据模型、常量与配置 ├── ViewModels/ # MVVM 视图模型，CommunityToolkit.Mvvm 驱动绑定 └── Views/ # Avalonia XAML 视图与窗口几个值得留意的点：
Core/Service/Music/下每个平台一对类：XxxApi是带缓存的对外门面，XxxNativeApi才真正拼 HTTP 请求，加新平台只需实现这对抽象；ViewModels/按功能窗口拆分（搜索、批量、模糊、设置、格式转换），消息对象放在Messages/子目录里做窗口间通信；- 仓库根目录的
archive-winform/是早期 WinForms 版本，留作演进对照，日常开发和运行只看cross-platform/这一侧； - 单测在
cross-platform/MusicLyricApp.Tests/，重点覆盖歌词时间戳、纯文本歌词解析等纯逻辑模块。
【免费下载链接】163MusicLyrics云音乐歌词获取处理工具【网易云、QQ音乐】项目地址: https://gitcode.com/GitHub_Trending/16/163MusicLyrics
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
