<p>TagLib# 是 C# 中读取 MP3 ID3 标签最可靠方案，自动兼容 ID3v1/v2.2/v2.3/v2.4，需检查 TagTypes 再取值，显式处理编码（如 UTF-8/GBK/Latin1），用 ReadStyle.Average 提升批量性能。</p>
用 TagLib# 读取 MP3 的 ID3 标签最可靠
直接调用 Windows API 或手动解析 ID3v2 头部容易出错，尤其遇到不规范的标签（如 UTF-16 编码、非标准帧、ID3v1/v2 混存）。TagLib# 是目前 C# 生态中维护最久、兼容性最好的开源库，能自动识别 ID3v1 / ID3v2.2 / ID3v2.3 / ID3v2.4，并处理各种编码和异常边界。
安装方式：dotnet add package taglib（.NET Core/.NET 5+）或通过 NuGet 安装 TagLibSharp（注意：新版本已更名为 TagLib#，旧包 TagLibSharp 已归档）。
TagLib.File.Create() 后必须检查 TagTypes 再取值
ID3 标签可能不存在，或只含部分字段（比如只有 ID3v1、没有 ID3v2），甚至文件根本不是 MP3。直接访问 file.Tag.Title 可能返回空字符串或默认值，但不代表标签没数据——只是当前 TagType 未被加载。
- 先判断
file.TagTypes是否包含TagLib.TagTypes.Id3v2或TagLib.TagTypes.Id3v1 - 再读取字段，例如：
file.Tag.Title ?? file.Tag.FirstAlbum ?? "未知标题" - 对多值字段（如艺术家、流派），用
file.Tag.AlbumArtists（数组）比file.Tag.AlbumArtist（单值）更稳妥 - 避免用
file.Properties.Duration当作时长来源——它依赖音频解析，而标签读取应尽量跳过解码
中文乱码？重点看 file.Tag.TextEncoding 和 BOM
很多老旧 MP3 的 ID3v2 使用 ISO-8859-1 编码写入中文，或未声明编码但实际用了 GBK；TagLib# 默认按 UTF-8 解析，就会显示为乱码或空值。
解决方案不是硬改源码，而是显式指定编码：
var file = TagLib.File.Create(path);
// 强制用 GBK 解析文本帧（适用于大量国产老资源）
if (file.Tag is TagLib.Id3v2.Tag id3v2Tag)
{
id3v2Tag.TextEncoding = TagLib.StringType.UTF8; // 先设为 UTF8（默认）
// 若发现 Title 为空且文件明显有中文标签，可尝试：
// id3v2Tag.TextEncoding = TagLib.StringType.Latin1; // 再试 Latin1（ISO-8859-1）
}
string title = file.Tag.Title;更健壮的做法是：对每个文本字段单独检测是否为空，再用 TagLib.ByteVector 读原始帧内容，手动按常见编码尝试解码。
批量读取性能差？别在循环里反复 Create()
TagLib.File.Create() 默认会读取整个文件头 + 所有标签帧，如果只是要标题/艺术家，没必要加载全部。可用 ReadStyle.Average 或 ReadStyle.None 控制读取深度：
-
TagLib.File.Create(path, TagLib.ReadStyle.Average)：只读 ID3 和 APE 标签，跳过音频数据解析，适合元数据提取 -
TagLib.File.Create(path, TagLib.ReadStyle.None)：仅读 ID3v1 和 ID3v2 头（最快，但可能漏掉某些 ID3v2.4 帧） - 不要在 foreach 中反复 new
TagLib.File，用using确保释放底层句柄
特别注意：某些网络路径（如 SMB 共享）下，ReadStyle.None 可能因无法 seek 而失败，此时需降级为 Average 并捕获 NotSupportedException。
ID3 标签的解析逻辑藏在字节边界和编码协商里，看似简单，实则每个字段背后都可能有三套编码、两种帧格式、一个损坏的 BOM。别信“一行代码获取标题”的示例，先确认你的 MP3 来源是否规范。
