说实话，作为一名在代码堆里摸爬滚打多年的前端开发者，我对 Electron 的感情一直hen复杂。它确实强大，让 Web 技术Neng够无缝切入桌面端，但那个动辄 100MB 起步的安装包体积，每次打包发布时dou像是在我的硬盘上割肉。特别是当我只是想Zuo一个简单的音乐播放器时为了那几兆的音频逻辑，不得不塞进去一整个 Chromium 内核和 Node.js 环境，这种“杀鸡用牛刀”的感觉实在让人抓狂。

Zui近项目空窗期，我决定 挑战一下自己，写一个桌面端音乐播放器练练手。但这次我受够了臃肿，把目光投向了Zui近风头正劲的 Tauri 2。听说它Neng把体积压缩到极致，而且性Neng表现不俗。经过一番折腾，当Zui终那个只有 3.5MB 的安装包生成时我差点没忍住叫出声来——这简直是从大象变成了蚂蚁！今天我就把这次从 Electron 迁移到 Tauri 2 的实战经验，连同那些踩过的坑和深夜调试的辛酸泪，一并分享给大家。

在移动应用开发中，音乐播放器是练手的经典项目，这点毋庸置疑。但在桌面端，Electron 长期以来占据着统治地位。然而它的弊端也显而易见。每个 Electron 应用dou自带了一个完整的浏览器内核，这意味着Ru果你的电脑上装了五个 Electron 应用，你就可Neng拥有五个 Chromium 实例在后台运行。这对于用户来说不仅是硬盘空间的浪费，geng是内存资源的无底洞。

我之前用 Electron Zuo过几个小工具，打包出来基本dou在 100MB 上下。对于一些功Neng复杂的重型应用尚可接受，但对于一个音乐播放器？这太荒谬了。用户下载一个播放器，结果大部分时间是在下载浏览器内核。而 Tauri 的出现，就是为了解决这个问题。它放弃了自带的庞大内核，转而调用操作系统自带的 WebView。后端逻辑则由 Rust 这门以安全和高性Neng著称的语言编写。这种架构上的根本性差异，直接决定了体积上的巨大鸿沟。

为了验证这个传闻，我分别用 Electron 和 Tauri 打包了一个 Hello World 程序进行对比。结果令人震惊：Electron 版本高达 62.5MB，而 Tauri 版本仅有 4.32MB。这不仅仅是数字的减少，geng是开发理念的胜利。kan到这个对比图时我几乎没有任何犹豫，立刻决定将我的音乐播放器项目全面迁移到 Tauri 2。

这次的技术栈非常现代且纯粹：Tauri 2 + Vue 3 + TypeScript。UI 方面我依然选择了熟悉的 Element Plus，毕竟它的组件库足够丰富，Neng让我把精力集中在业务逻辑上，而不是纠结于 CSS 样式。

对于前端开发者来说Tauri 的学习曲线其实非常平缓。你不需要立刻成为 Rust 专家，因为 Tauri 2 的插件系统设计得相当精妙。大部分常用的功Neng，比如文件系统访问、对话框、数据存储等，dou有现成的插件Ke以直接使用。这些插件通常dou带有完整的 TypeScript 类型定义，开发体验极佳，IDE 的智Neng提示Neng帮你省去不少查文档的时间。

配置方面Tauri 相比 Electron 的那种复杂配置文件，显得geng加清爽。大部分权限和配置dou集中在 src-tauri/capabilities/default.json 这个文件里。你需要什么权限，就在这里声明，这种“Zui小权限原则”的设计让应用的安全性geng有保障。比如我的播放器需要读取文件和保存设置，配置大概是这样的：

{
  "identifier": "default",
  "description": "Default capability",
  "windows": ,
  "permissions": 
}

开发过程中遇到的第一个拦路虎，就是浏览器安全策略对本地文件访问的限制。在传统的 Web 开发中，出于安全考虑，浏览器是不允许直接通过 file:// 协议加载本地资源的。一开始，我天真地以为Ke以直接把本地路径赋给 HTML5 的 Audio 标签，结果可想而知——毫无反应，控制台里报错提示安全限制。

这确实让人头大。不过既然是桌面应用，总得有办法绕过去。Tauri 的 fs 插件提供了读取文件内容的Neng力，返回的是一个 Uint8Array。既然不Neng直接给路径，那就把文件读进来转成浏览器Neng识别的 Blob 对象，再生成一个临时的 URL。虽然听起来有点绕，但这确实是目前Zui稳妥的方案。

具体的实现逻辑大概是这样：先用 readFile 读取文件二进制流，然后构造 Blob，Zui后用 URL.createObjectURL 创建一个可访问的链接。

const fileContent = await readFile;
const blob = new Blob;
const audioUrl = URL.createObjectURL;
const audio = new Audio;

这里有个小细节需要注意，URL.createObjectURL 创建的对象会一直占用内存，直到页面关闭或者手动调用 revokeObjectURL。对于音乐播放器这种场景，音频 URL 可Neng会一直被引用，所以不需要急着释放。但Ru果你在处理大量图片或者临时文件时一定要记得手动清理，否则hen容易造成内存泄漏。这也是我在开发过程中踩过的一个坑，调试了好久才发现是这里没处理好。

一个合格的播放器，必须Neng自动扫描用户指定的音乐文件夹。这涉及到递归遍历文件树的操作。Tauri 的 fs 插件提供了 readDir 方法，支持递归读取，这省去了我自己写递归逻辑的麻烦。

在拿到文件列表后我们需要过滤出音频文件。我定义了一个支持的格式数组，比如 ，然后遍历文件列表进行匹配。Ru果是文件夹，就继续递归处理；Ru果是文件且后缀名匹配，就将其加入播放列表。

const entries = await readDir;
function collectMusicFiles {
  for  {
    const fullPath = basePath + '\\' + entry.name;
    if  {
      // 是文件，检查是否是音乐文件
      if )) {
        musicFiles.push;
      }
    } else {
      // 是文件夹，递归扫描
      collectMusicFiles;
    }
  }
}

除了文件名，我们还需要展示歌曲的标题、艺术家、专辑封面等信息。Tauri 本身并没有提供专门读取音频元数据的插件，这就需要借助前端的库了。我选用了 jsmediatags。这个库虽然有点年头了但依然Neng打。不过它只支持读取 Blob 对象，这正好和我们前面生成的 Blob 对象衔接上了。

读取过程是异步的，我们需要处理成功和失败的回调。Ru果文件没有元数据，或者读取失败，就优雅降级，用文件名作为标题，艺术家显示为“未知艺术家”。

jsmediatags.read(blob, {
  onSuccess:  => {
    artist = tag.tags.artist;
    album = tag.tags.album;
    // ...处理其他信息
  },
  onError:  => {
    console.error;
    // 设置默认值
  }
});

为了提升用户体验，我还增加了一个自动加载封面和歌词的功Neng。逻辑hen简单：假设音乐文件名为 song.mp3，程序会尝试在同一目录下查找 song.jpgsong.png 等图片作为封面查找 song.lrc 作为歌词文件。这种约定优于配置的方式，用户整理好文件后打开播放器就Nengkan到完美的效果，非常省心。

音乐播放器Ru果没有歌词同步，灵魂就少了一半。LRC 格式的歌词其实hen简单，就是一行行带有时间戳的文本。解析的关键在于正则表达式。时间戳通常是 的格式，其中毫秒部分可Neng是 2 位也可Neng是 3 位，需要统一补齐处理。

我写了一个正则来匹配每一行：

const match = line.match:\.\]/);
if  {
  const minutes = parseInt;
  const seconds = parseInt;
  const milliseconds = parseInt);
  const time = minutes * 60 + seconds + milliseconds / 1000;
  const text = match.trim;
  // 存储解析后的时间和文本
}

解析完歌词后就是实时同步了。一开始我想着用 setInterval 定时去检查当前播放时间，然后匹配歌词行。但转念一想，这种方式太笨拙了而且性Neng不好，容易造成页面卡顿。geng好的方案是利用 HTML5 Audio 的 timeupdate 事件。这个事件会在播放进度geng新时触发，频率适中，完全Neng满足需求。

在事件处理函数中，我们遍历解析好的歌词数组，找到当前时间对应的Zui后一句歌词显示出来即可。这里要注意边界条件的处理，比如歌曲刚开始或者刚结束时的状态。

audio.addEventListener => {
  updateCurrentLyric;
});
function updateCurrentLyric {
  let currentIndex = -1;
  for  {
    if  {
      currentIndex = i;
    } else {
      break;
    }
  }
  if  {
    currentLyricText.value = currentLyrics.value.text;
  }
}

进度条的拖动也是一个交互重点。用户拖动进度条时应该暂停播放，拖动结束后再跳转到指定位置。Element Plus 的 Slider 组件提供了hen好的支持，通过 v-model 绑定数据，再监听 change 事件来触发 audio.currentTime 的geng新。不过要注意，duration 属性必须在 loadedmetadata 事件触发后才Neng获取到，否则会是 NaN，导致计算出错。

桌面应用的数据持久化一直是个小问题。Web 开发中常用的 localStorage 在 Tauri 环境下虽然Neng用，但总觉得不太靠谱，容量受限且路径不透明。万一用户清理缓存，辛辛苦苦整理的歌单岂不是没了？

为了保险起见，我使用了 Tauri 官方的 @tauri-apps/plugin-store 插件。这个插件会在应用目录下创建一个 JSON 文件专门用来存储数据。它的 API 设计得非常简洁，setgetsave 一气呵成，而且支持异步操作，不会阻塞主线程。

const store = await Store.load;
// 保存数据
await store.set;
await store.set;
await store.save;
// 读取数据
const savedSongList = await store.get;
const savedFolder = await store.get;

用了这个之后心里踏实多了。不管用户怎么折腾浏览器缓存，我的播放列表dou稳稳地躺在那个 JSON 文件里。

经过这段时间的开发，我对 Tauri 2 的好感度直线上升。相比 Electron，它Zui大的优势无疑是那令人发指的体积缩减——从 100MB 降到了 3.5MB，这简直是降维打击。虽然对于我这个简单的音乐播放器来说性Neng上的提升感知不是hen强，但启动速度明显快了内存占用也低了不少。

当然Tauri 并不是完美的。Ru果你需要极其底层的系统控制，或者你的应用严重依赖 Node.js 的生态，那么 Electron 可Neng依然是geng稳妥的选择。但对于大部分前端开发者想要构建的轻量级桌面工具，Tauri 2 绝对是目前的Zui佳选择之一。

它的插件系统极大地降低了 Rust 的入门门槛，让我们这些只懂 JavaScript 的人也Neng享受到 Rust 带来的安全红利。配置清晰、类型完善、打包体积小，这些优点加在一起，足以让人忽略它学习过程中的一点点小波折。

总的来说这次用 Tauri 2 打造音乐播放器的体验非常棒。它让我重新找回了写代码的乐趣，而不是在打包和优化性Neng中焦头烂额。Ru果你还在犹豫要不要尝试 Tauri，我的建议是：别犹豫了赶紧上车吧！那个只有几兆大小的安装包，会让你在朋友面前倍儿有面子。项目源码我Yi经开源了欢迎大家去 GitHub 上 Star 和 Fork，一起在这个轻量化的道路上越走越远。