Go 读取 MP3 ID3 标签需用 github.com/mikkeloscar/id3v2，通过 os.Open 传 *os.File 给 id3v2.ReadFrom 实现高效解析，避免 os.ReadFile 加载整文件导致内存溢出。
怎么用 Go 读取 MP3 文件的 ID3 标签
Go 标准库不支持 ID3 解析，必须依赖第三方包；github.com/mikkeloscar/id3v2 是目前最轻量、兼容性最好的选择，能处理 v2.3/v2.4，且不强制解码整个文件。
常见错误是直接用 os.ReadFile 加载整首 MP3——大文件（比如 100MB 无损转录）会吃光内存。正确做法是用 os.Open 获取 *os.File，再传给 id3v2.ReadFrom，它只读标签所在头部区域（通常前几百字节）。
- 安装：
go get github.com/mikkeloscar/id3v2 - 务必检查返回的
err：ID3 标签可能不存在（返回id3v2.ErrNoID3Tag），不是所有 MP3 都有标签 - 注意编码：
frame.Text默认是 UTF-8，但老文件可能是 ISO-8859-1，需用frame.Encoding判断并手动转换
如何安全地移动文件并保留原始路径结构
用户常把音乐丢在 ~/Downloads 或 ~/Desktop，分类后想按歌手/专辑归到 ~/Music/Artist/Album/。直接 os.Rename 有风险：跨磁盘失败、目标目录不存在、权限不足都会 panic。
核心原则是「先建目录，再移动，最后校验」。不要信任 os.MkdirAll 一次调用就万事大吉——它不保证父目录可写，也不检查目标是否已是文件而非目录。
立即学习“go语言免费学习笔记（深入）”；
虚拟歌手场景 MV 制作流水线。输入音乐音频、歌词、视频脚本、虚拟歌手三视图参考图，自动生成完整场景 MV。支持 AI 动态视频、风格化动画模板、3D 模型三种动画模式。不支对口型。
- 用
filepath.Join拼路径，别手拼"Music/" + artist + "/" + album（Windows 下反斜杠会崩） - 移动前用
os.Stat确认源文件存在且是普通文件；目标目录用os.Stat+os.IsNotExist判断，再os.MkdirAll - 用
os.Chmod显式设目标目录权限为0755，避免某些 NAS 或 WSL 挂载点默认无执行位导致后续无法进入
命令行参数怎么设计才不反直觉
用户实际使用时，不会记一堆 flag。比如 music-sort -src ~/Downloads -dst ~/Music -dry-run 看起来合理，但「干运行」模式下如果没输出具体要移动哪些文件，就失去意义。
真正关键的是默认行为：不加任何 flag 就该扫描当前目录下的 MP3 并分类到 ./sorted，而不是报错或静默退出。否则新手连第一步都卡住。
-
-src和-dst必须是绝对路径或从当前目录解析的相对路径，禁止接受 glob（如"*.mp3"），那属于 shell 职责 -
-by参数控制分类维度，值只能是"artist"、"album"或"artist/album"，其他值立刻报错并列出选项 - 所有 flag 都要带默认值，
-dry-run默认 false，-by默认"artist/album"，-src默认"."
为什么遍历大量小文件时 CPU 占用低但耗时很长
这不是 Go 的问题，而是 I/O 等待占主导。每个 os.Stat 和 id3v2.ReadFrom 都触发一次系统调用，硬盘寻道+缓存未命中会让吞吐骤降。SSD 上 1000 个文件可能只要 2 秒，机械盘上可能要 15 秒以上。
优化方向不是并发开 goroutine（太多反而压垮磁盘队列），而是减少系统调用次数和预读缓冲。
- 用
filepath.WalkDir（Go 1.16+）替代filepath.Walk，它不强制 Stat 每个子项，能跳过非 MP3 文件的 Stat - 对每个 MP3 文件，先用
os.Open打开，再用file.Seek(0, io.SeekStart)复位，接着传给id3v2.ReadFrom—— 这样比反复 Open/Close 快 20%~30% - 完全放弃「实时显示进度」：每处理 10 个文件才
fmt.Printf一次，避免频繁刷屏阻塞主线程
最容易被忽略的是文件名乱码问题：Windows 用户拖进来的 MP3，文件名可能是 GBK 编码，而 Go 的 os 接口一律当 UTF-8 处理，导致 os.Rename 失败却报 "invalid argument"。这事没法自动修复，只能文档里明确提醒「请确保文件名是 UTF-8」。
