把弹幕「打包」带走，解锁高清版视频的吐槽自由

编注：本期内容为少数派 Matrix 社区应用自荐文章合集。文章代表作者个人观点，作者与文中产品有直接的利益相关（开发者、自家产品等），少数派仅对标题和排版略作修改。

本期目录1️⃣ 弹弹play：把弹幕打包带走3️⃣ Tutti：一个声音，响遍全场3️⃣ DeskBox：你的桌面，终于可以井井有条

弹弹play

‍ Belcheck | iOS / macOS / Android / PC / Web | 下载地址

弹幕大概是少数几种会让人留念 B 站的东西。

有些视频，我更愿意在原作者的 YouTube 频道或自己的高清媒体库里观看：画面更清楚，压缩更少，也可能保留了更完整的内容。但少了 B 站同一时间点飘过的一句吐槽，观看体验似乎也跟着少了一块。

有时候，真正让我笑出来的并不完全是视频本身，而是画面和弹幕共同完成的：某句似曾相识的台词、一个固定出场的道具，或者创作者刚挖完坑，观众已经提前在屏幕上报出了答案。

画面可以换一个地方看，这种共同观看的感觉却很难一起带走。

于是我做了「弹来弹去」：粘贴一个 B 站视频链接，它只获取弹幕，不下载、也不播放视频，再通过一层透明置顶窗口，把弹幕覆盖到 YouTube、Infuse、IINA、QuickTime 等播放器上。

现在它已经支持 macOS 和 Windows，并在 GitHub 开源。

▍画质和弹幕，为什么非要二选一？

从数据上看，视频和弹幕本来就是两套相对独立的内容。

视频负责画面与声音；弹幕只需要知道两件事：应该显示什么，以及应该在第几秒出现。既然如此，弹幕并不一定非得被锁在某个网页或某个播放器里。

只要在视频窗口上方放置一层透明、置顶的弹幕窗口，底下播放的是浏览器里的 YouTube、Infuse 中的个人媒体库，还是 IINA、QuickTime 里的本地文件，在窗口化播放场景里都没有本质区别。

我最初以为，这是一个应该早就被解决的问题。

后来搜索才发现，类似方案并非没有：弹弹play 在 Windows 上支持把弹幕覆盖到 PotPlayer、mpv、MPC 等指定播放器；Danmaku Anywhere 可以给网页视频加载弹幕；IINA 和 mpv 也有各自的弹幕插件。

但我的需求刚好落在这些方案之间：

不想为了看弹幕更换自己习惯的播放器；

不希望工具接管或重新播放视频；

既要覆盖浏览器，也要覆盖 Infuse、QuickTime 等原生应用；

既然现成方案没有完全落在这个交集里，我决定自己做一个。

▍一个只负责弹幕的 App

「弹来弹去」的使用流程只有四步：

粘贴 B 站视频链接，支持 BV、av、分 P 和 b23.tv 短链；

获取对应视频的弹幕；

打开透明弹幕层，并把它放到视频画面上方；

在任意播放器中打开对应的视频，完成一次时间同步。

它不读取视频内容，也不知道弹幕窗口下面正在播放什么。你可以用 Infuse 播放自己的媒体库，在 IINA 里打开本地文件，也可以直接在浏览器里观看 YouTube。只要两边是内容和时间轴大致对应的同一段视频，就能把它们组合起来。

这种设计的好处是通用：我不需要为每个播放器分别实现一套视频加载逻辑，更不会碰到画质、字幕、HDR、音轨、网盘协议或播放权限等问题。

它只做弹幕，其余事情继续交给用户已经选择好的播放器。

但这种通用性也带来了整个项目最麻烦的问题。

▍它怎么知道视频播放到哪里了？

答案是：它不知道。

因为「弹来弹去」不读取下方播放器的状态，所以无法自动知道视频正在播放、暂停，或者已经快进到了第几秒。

最理想的体验当然是自动同步：播放器暂停，弹幕也暂停；播放器跳转，弹幕跟着跳转；播放速度改变，两条时间轴始终保持一致。

但如果要实现这种体验，就需要分别适配浏览器、Infuse、IINA、QuickTime 以及其他播放器。有些可以通过脚本或辅助功能获取状态，有些只能间接猜测，还有些系统级全屏场景根本不允许外部窗口覆盖。

对于一个只为了解决个人观看需求的小工具来说，这很容易变成一项永远做不完的工程。

我最后选择了一个更朴素的办法：让弹幕使用自己的时间轴，再通过一次手动操作和视频完成同步。

加载弹幕后，点击「5 秒后从 0 同步」，弹幕层中央会出现倒计时。我只需要把鼠标放到播放器的播放按钮上，在倒计时归零时开始播放视频即可，这一个设计可以让用户在使用时不用受忙脚乱地去对齐进度。

如果两边相差一点，还可以使用 ±1 秒、±5 秒按钮或直接输入精确偏移进行微调。在我自己的使用中，只要两个版本没有明显的片头或剪辑差异，通常十秒左右就能对齐。

完成同步后，App 会保存这个视频的播放位置和时间偏移。下次从历史记录打开时，可以直接从上次的位置继续，不需要重新从头校准。

它没有自动同步那么优雅，但足够简单，也足够可靠。

当然，这个方案也有明确边界：如果两个版本的片头不同，可以用偏移解决；如果中间存在删减或重新剪辑，后半段仍可能再次错位。通用性并不是免费的，它只是把 「适配每个播放器」 的复杂度，换成了用户偶尔进行一次手动校准。

▍真正好用的工具，应该尽量 「消失」

弹幕层位于播放器上方，但平时不应该妨碍播放器操作。

因此我加入了「鼠标穿透」：开启后，点击、拖动进度条、切换全屏等操作都会直接落到下面的播放器上；需要调整弹幕层的位置和尺寸时，再暂时关闭穿透，窗口边缘会出现提示边框，可以直接拖动和缩放。

主窗口也被压缩成两个主要步骤：第一页选择弹幕来源，可以粘贴链接或从历史记录继续观看；第二页只保留播放、暂停、进度、同步和微调。倍速、清屏、鼠标穿透和导入导出等低频操作，都收进二级菜单。

观影时，我通常不会再切回主窗口，而是使用全局快捷键控制弹幕：

播放或暂停弹幕；

前后微调 1 秒或 5 秒；

从当前时刻重新同步；

显示或隐藏弹幕层。

这看起来只是一些很小的功能，却直接决定了一个 App 是只能演示一次，还是愿意在下次看视频时重新打开。

▍从「能运行」到「愿意一直用」

最早的版本只完成了四件事：解析链接、获取弹幕、渲染弹幕，以及让弹幕开始或暂停。

剩下的功能，几乎都来自实际使用中的不满。

拖动进度条时，时间数字没有同步变化；主窗口信息太多；开启鼠标穿透后，很难再把控制窗口找回来；长时间观看后，两边的时间轴可能产生轻微偏差。

这些问题单独看都不严重，但它们决定了一个「能运行的 Demo」 能否变成真正愿意反复打开的工具。

因此，我补上了播放状态、历史记录、进度保存、全局快捷键、偏移微调、窗口位置记忆、显示区域、密度控制和过滤功能。时间轴与窗口状态也做了自动测试，避免修复一个问题时又破坏另一个使用场景。

工具类产品最容易忽略的，往往不是核心功能，而是核心功能前后的十几个小动作。

▍macOS 的 Liquid Glass，以及后来的 Windows 版

macOS 版采用原生 AppKit 开发，并使用了 macOS 26 Tahoe 的 Liquid Glass 界面。主控制窗口使用玻璃材质卡片和按钮，深色模式下则选择了偏粉色的强调色，希望它看起来像一个系统工具，而不是套着网页外壳的播放器。

使用新系统 API 的代价也很直接：目前 macOS 版要求 macOS 26 或更高版本。为了兼容更旧的系统重新实现整套界面，会让这个个人项目多出不少维护成本，因此第一阶段我选择先把体验做好。

后来我又做了 Windows 10/11 x64 原生版本。它采用 .NET 8 和 WPF，同样包含透明置顶弹幕层、鼠标穿透、分 P、时间轴同步、过滤、历史记录和全局快捷键。安装包是自包含版本，用户不需要额外安装 .NET Runtime。

两个版本没有追求界面上的完全一致，但核心工作方式相同：视频由原来的播放器负责，弹幕由一层独立窗口负责。

▍弹幕也可以不挡住画面

一位朋友试用后，向我提到了另一个起初没有想到的使用场景。

看经典电影，或者摄影、作画特别出色的动画时，人会更想好好欣赏完整的构图、光影和细节。弹幕依然有趣，但让文字从人物面前和精心设计的画面上不断飘过，有时也会破坏观看体验。

在站内播放器里，弹幕终究与视频共用同一块画面。即使可以调整透明度和显示区域，想在关键镜头完全不受遮挡，往往还是需要手动打开和关闭弹幕。

但「弹来弹去」的弹幕层本身就是一个可以自由移动、缩放的独立窗口，你想调整成任何比例，放在任何位置都可以，因此弹幕并不一定要盖在视频上。

只有一块屏幕时，可以把视频窗口放在屏幕上半部分，把弹幕层放在下半部分：上面只保留完整画面，下面继续显示观众在同一时间点留下的反应，两边互不遮挡。

如果有两块显示器，还可以把视频放在主屏，把弹幕层单独放到副屏。主屏用来专心看电影，副屏则像一条与影片同步的观众席 —— 想看时转一下视线，不想看时也不会干扰画面。

这也是独立窗口带来的另一个价值：它不只是把 B 站弹幕带到其他播放器，也让画面和弹幕可以在空间上彼此分离。弹幕既可以覆盖在视频上，也可以退到画面之外，成为一条独立的观看层。

像播客类的节目，本身画面就不重要，你甚至可以一边开着弹幕一边查阅其他资料，比如这样：

▍下载、限制与边界

「弹来弹去」目前已经在 GitHub 开源，采用 GPL-3.0 许可证：

查看源代码与完整使用说明

目前有几项限制需要提前说明：

macOS 版要求 macOS 26 Tahoe 或更高版本；Windows 版支持 Windows 10/11 x64；

工具仅使用无需登录即可访问的公开接口，不携带 Cookie，因此获取到的是当前公开弹幕池，不一定包含全部历史弹幕；

当前支持 BV、av、分 P 和 b23.tv 短链，暂不支持番剧 ep/ss 链接与互动视频；

工具不下载视频，也不会绕过视频平台的播放权限；

独立弹幕层在系统原生独占全屏下可能无法显示，可改用窗口最大化，或导出 ASS 字幕作为兜底；

视频版本存在中途删减或重新剪辑时，弹幕可能需要再次校准。

这是一个独立第三方开源工具，与哔哩哔哩没有关联、授权或合作关系。弹幕内容的权利归原发送用户及平台所有，请仅用于个人观看辅助，不要用于批量抓取或商业用途。

▍还想继续做什么

现在的版本已经解决了我最初的问题：在 Infuse 中播放自己的高清媒体库，或者在 YouTube 上观看创作者发布的版本时，仍然能够保留 B 站弹幕。

但还有一些方向值得继续尝试。

比如把弹幕密度显示成时间轴热力图。弹幕数量往往能反映视频的情绪高点，即使不读取具体内容，也可以提前知道接下来哪里可能发生有趣的事情。

我也考虑过制作一个浏览器扩展，用来读取 YouTube 等网页播放器的当前进度，再与桌面 App 通过本地连接自动同步。它会让网页观看体验更加完整，不过也意味着需要针对不同网站持续适配。

至少在现在，我仍然更愿意先保持这个工具的简单：

视频归播放器管，弹幕归「弹来弹去」管。

我们早已习惯把视频、字幕和音轨自由组合。也许弹幕同样不应该永远被锁在某一个网站里。

有些视频值得用最好的画质观看，而有些梗，确实需要大家一起笑才完整。

弹弹play ： https://www.dandanplay.com/

Tutti

‍ Barrybarrywu | iOS / macOS | 下载地址

从一个听起来很简单的需求开始

我用 Mac 的时候，习惯常年在桌面上接一台显示器，有时还会连上蓝牙音箱。但是有个问题一直困扰我，它们明明都能发出声音，但 macOS 默只能选择其中一个作为声音的输出。

于是我就想：既然面前已经有两三个扬声器，为什么不能让它们同时播放？声场效果不是更好吗？

系统其实做得到，只是做完以后更难用了

于是我上网找了一圈，发现很多人也有和我一样的困惑，然后看到有人推荐，使用 macOS 自带的 「音频 MIDI 设置」，可以创建多输出设备。把几个输出勾选进去之后，同一个声音确实能从多个设备里一起出来。

但创建多输出设备后，平音量键不再像原来那样工作；想调整声音大小，你要一个个调，它没有一个总音量可以同时调整所有的设备。临时切换设备或重新组合时，也要再回到 「音频 MIDI 设置」 里操作，这个就很方便了。

更明显的问题是延迟。显示器、Mac 内置扬声器和蓝牙音箱处理声音的速度并不相同。只要其中一台慢了一点，就会感觉到声音对不齐，听起来像在 KTV 里几个人抢着唱同一句。

MacOS 系统已经提供了 「让它们一起响」 的底层能力，却没有把它变成一套适合每天使用的控制体验。原本只是想多开一个音箱，最后却要面对音量、同步和切换三个问题。

MIDI 设置

我先找了一圈现成方案

MIDI 这条路走不通，于是我在想是不是已经有其他更好的 APP 解决，可以解决这个问题？

我先后看了 FineTune、SoundSource 和 Loopback 等工具。它们各有不同的重心：有的主要解决按 App 调整音量，有的提供更完整、更专业的音频路由能力。

这些产品也让我逐渐确认，我真正想解决的并不是 「给 APP 再加一个音量滑块」，而是把多个实体输出设备当作一组来管理：快速选择设备、统一控制总音量、保留各自的音量大小，并补偿不同设备之间的延迟。

我尤其在意最后一点。桌上的蓝牙音箱总是比 Mac 自带扬声器慢一点，而我没有找到一套完全符合自己操作习惯的解决方式。那我就想，既然没有合适的，我就自己做一个好了，反正现在 AI 编程这么强了。这才成为我开始做 Tutti 的理由。

把多输出设备重新放回菜单栏

现在的 Tutti，是一个常驻菜单栏的原生 Mac 应用。打开面板后，可以像选择普通输出一样勾选多个设备，让 Mac 内置扬声器、显示器、蓝牙音箱、耳机或 USB 音频设备同时播放。对了，它也可以实现类似 iPhone 上接入两个 AirPods 的同步功能。我不懂为什么苹果在 iOS 上做了这个功能，但是在 MacOS 上却没有把它带进来。

以我桌上的显示器和蓝牙音箱为例，我可以先调整各自的响度，再用一个总音量统一控制整组设备。下次使用时，把这套组合存成预设，不必再回到 「音频 MIDI 设置」重新创建。

如果两个设备没有同时发声，还可以单独增加某台设备的延迟。Tutti 不能让较慢的蓝牙设备凭空变快，它做的是把更快的设备稍微往后推，尽量让两边重新对齐。

另一个场景是按 App 控制声音。在 macOS 14.4 及以上，可以分别调整不同 App 的音量、EQ 和输出位置。例如把音乐送到显示器，把浏览器送到另一台扬声器，减少来回切换系统输出的次数。

我还做了个 Tutti Theater 功能，可以把把一只音箱设为左声道，另一只设为右声道。相当于把独立的音箱组成一套立体声系统，让左右声道分别从不同设备播放，而不是所有设备播放相同的混音。之前你在耳机里面才能听到的左右声道，现在在桌面上也可以听到了。

我甚至还做了一个 iPhone 的遥控 APP，使用 iPhone 就可以控制 Mac 上的各个设备的音量、APP 的音量，以及查看现在播放的信息。

这些功能看起来分散，其实都围绕同一个目标：把多设备播放从一次性的系统设置，变成菜单栏上的一个小工具。

为什么我坚持不安装虚拟音频驱动

开发 Tutti 时，我给自己定了一条边界：尽量使用 macOS 已经提供的 Core Audio 能力，不额外安装虚拟音频驱动、内核扩展或系统扩展。

当用户选择多个输出时，Tutti 会在系统能力范围内临时组织这些设备；退出应用后，再恢复此前的系统音频输出。我希望它像一个随时可以关掉的菜单栏工具，而不是接管整套音频环境的基础设施。

这并不是说虚拟音频驱动不好。对于录音、直播或复杂混音，它们能提供更完整的路由能力。只是 Tutti 面向的是日常播放和设备控制，我更愿意用较轻的实现，换取更简单的安装、退出和恢复过程。

这个选择也意味着 Tutti 有明确边界。它不能代替专业音频工作站，也不会覆盖所有路由需求；我更关心的是，让普通用户在连接显示器、音箱和耳机时，不必先理解一整套专业音频概念。

从能运行的 Demo 到愿意长期维护的产品

这是我第一次真正把一个 App 从想法、代码和测试，一直做到官网、写帮助文档、接入支付与售后系统。第一版很快就能用了，但我后来才发现，「能运行」 和 「可以交给别人长期使用」 之间，还有很长一段距离。

真正耗费时间的，是各种不在 Demo 里的事情：不同品牌设备的行为、蓝牙重新连接、系统版本变化、异常退出后的恢复，以及某些 App 特有的兼容问题。

最初我的脑袋里有很多想做的功能，但是我也不知道功能优先级应该怎样排列，更不知道这个需求是否只属于我自己。后来我找了一些用户测试，根据他们连接的设备、实际使用方式和遇到的问题，持续迭代了一个多月，才决定正式发布。

用户反馈

这段经历也改变了我对 Vibe coding 的看法。借助现有 AI Agent 做出一个能跑的原型 Demo 并不难，难的是理解每一处行为，并愿意继续处理反馈、兼容性和边缘问题。一个产品真正的工作，往往从 Demo 能运行之后才开始。

我从一开始就不想让 Tutti 停留在免费 Demo。基础功能可以免费使用，高级功能采用一次买断，用户第一次下载就提供 Pro 的高级功能七天试用。我希望商业化带来的不是更激进的功能限制，而是让我有理由继续维护这个小工具，并对用户遇到的问题负责。

它现在适合谁，又不适合谁

如果你的 Mac 经常连接显示器、蓝牙音箱、USB DAC 或多副耳机，或者你希望分别控制不同 App 的声音，Tutti 会比较接近它最初想解决的场景。

应用本体支持 macOS 13 及以上；按 App 调整音量、EQ 和输出需要 macOS 14.4 及以上。如果使用较早的系统，仍然可以使用多设备输出和设备控制，但不会出现应用级功能。

它目前也有一些明确限制。AirPlay 设备不能加入 Tutti 的多输出组合，因为苹果并没有开放这部分的 API。但是呢，我尝试自己使用其他的方法，让 iPad 跟 iPhone、还有其他 Mac 也可以加入到输出设备里，预计会在下一个大版本里面更新；部分 App 或 macOS 测试版可能出现 Core Audio 兼容问题。如果你的核心需求是 HomePod、AirPlay 多房间播放或专业录音路由，Tutti 并不适合替代对应的专业方案。

我宁愿把这些边界提前写清楚。音频工具和每个人手上的硬件关系很大，同一个功能在显示器、蓝牙音箱和 USB 声卡上的体验可能并不完全相同。

与同类对比

我还想知道大家音响系统是怎么样的？

Tutti 最早来自我自己的桌面，但发布以后，我发现大家的音响设备比我想象得复杂得多。有人连接两台显示器，有人需要连接声卡，也有人同时处理会议、音乐和浏览器声音。

所以我现在最想知道两件事：你平时会给一台 Mac 同时连接哪些音频设备？在统一音量、设备同步和按 App 分配输出之间，哪一个问题最影响你的日常使用？

如果你愿意尝试，也欢迎把 macOS 版本、设备型号和具体问题告诉我。即使 Tutti 目前不能解决，这些真实场景也会帮助我判断下一步应该先做什么。

• Tutti 官网下载 ： https://tutti.barrybarrywu.com/

• GitHub 版本记录： https://github.com/BarryBarrywu/tutti

• 更多心得： https://b23.tv/UwGlKqb

• 产品演示： https://b23.tv/UebCv99

DeskBox

‍ 大雨实验室 | Windows | 下载地址

关联声明：DeskBox 是我‌使用 AI Vibe Coding 独立开发的项目，目前在 Github 免费开源，本文不含付费推广，本文部分内容使用了 AI 进行辅助创作。

这是我第一次在少数派写文章，想先聊一个大多数人每天都会面对的问题：Windows 桌面为什么总是很容易变乱？

截图、压缩包、微信接收的文件、临时导出的表格、过几天还要处理的资料，全都很自然地落到桌面上。刚开始只有几个，后来慢慢铺满整个屏幕。偶尔整理一次，通常也只是把它们塞进一个叫作 「新建文件夹」 的地方。

这不完全是因为懒。

桌面本来就是电脑上最顺手的临时空间，但 Windows 给它的组织方式一直比较单一：文件、文件夹，以及摆放位置。我们可以把文件放进文件夹，却很难在不离开桌面的情况下，看清文件夹里有什么，也很难同时保留「随手放」和「有秩序」 这两件事。

我试过把桌面彻底清空，也试过启动器、快捷方式和一些桌面美化工具。它们各有用处，但我真正想要的并不是另一个启动器，也不是把桌面替换成一套全新的工作台。

我只是想给原来的 Windows 桌面，多加一层简单的整理能力。

所以我做了 DeskBox。

它简洁，轻量，克制，免费开源，且完全遵循 windows 设计规范，能完美与 windows 的设置，个性化联动。包括明暗模式，主题色，材质，圆角组件等。

▍格子不是桌面上的装饰

DeskBox 最基础的东西，是一个个可以独立摆放和调整大小的文件格子。

其中一种叫「收纳格子」。它背后对应一个真实文件夹，把文件拖进去，就会移动到对应目录。你在资源管理器里仍然能看到这些文件，也可以正常复制、重命名、删除和打开。DeskBox 不会把文件塞进自己的数据库，更不会把它们变成只有软件自己认识的格式。

另一种是「文件夹映射」。如果已经有整理好的项目目录、下载目录或素材文件夹，可以直接把它映射成格子。它只提供桌面上的查看和操作入口，不改变原文件的位置。

这两种方式看起来很像，解决的却是不同的问题。

收纳格子适合接住桌面上不断出现的临时文件；文件夹映射适合把经常打开的目录带到桌面上。一个负责「把东西放进去」，一个负责「让我随时看得到」。

我很在意这一点，因为文件整理工具最不应该做的事情，就是把用户的文件困在工具里。

哪天不想用 DeskBox 了，文件依然是原来的文件，文件夹也依然是原来的文件夹。

当然，如果你是第一次使用，也不用担心，DeskBox 里面有完整的新手指导，几步就能理解并快速上手。

▍桌面上需要的，不只是文件

真正使用一段时间后，我发现桌面上让人分心的并不只有文件。

有时是一件今天必须完成的小事，有时是一段稍后还要复制的文字，有时只是想看一眼天气，或者切到下一首歌。

如果每次都要打开一个完整应用，处理成本反而有点高。所以 DeskBox 后来增加了待办、随记、天气和音乐几类功能格子。

但我并不想把它们做成对应专业软件的缩小版。

待办不是另一个复杂的项目管理系统。它适合快速记下一件事，在桌面上看见它，需要时再进入详情设置截止日期、提醒和重复。

随记也不是知识库。它更像一张临时放在桌面上的纸，可以写文字、放图片、固定常用内容，再用不同纸张稍微区分一下用途。

音乐格子只连接 Windows 的系统媒体会话，用来显示封面、歌名和常用播放控制；天气格子则根据尺寸自动改变信息密度，小尺寸看当前天气，拉大后再展示逐小时和多日预报。

这些格子的共同点是，它们都应该在需要时离手边很近，不需要时又足够安静。

▍不一直置顶，也不彻底消失

桌面格子有一个很麻烦的问题：窗口层级。

如果始终置顶，它们会挡住浏览器、文档和聊天窗口；如果固定在桌面底层，真正需要的时候，又得先最小化一堆窗口才能找到。

DeskBox 默认采用动态层级。通过托盘或快捷键唤起时，所有格子会回到前台；之后不再强行霸占最上层，而是把窗口关系重新交给 Windows 管理。

你点击其他应用，其他应用就会自然盖在格子上面；再次点击某个格子，它只会回到当前窗口之前。点击格子标题时，则可以一次唤起全部格子。

这套逻辑听起来不算复杂，实际却花了我很长时间。多显示器、Win+D、快捷键、托盘、全屏窗口和不同的点击顺序，都会改变最终结果。

它也是桌面工具和普通应用很不一样的地方：很多体验没有一个可以直接套用的标准答案，只能真的把它放在桌面上，每天去用。

▍我喜欢那些不太显眼的反馈

DeskBox 基于 WinUI 3 和 Windows App SDK 开发。我会优先使用 Windows 原生组件、系统材质和窗口能力，只有原生方案无法满足时，才自己绘制。

我不希望它看起来像一个盖在 Windows 上面的网页，也不希望每个操作都配上很夸张的动画。

比如调整格子大小时，边缘靠近其他格子或屏幕边界，会出现辅助参考线。参考线有一点很轻的呼吸效果，不是为了炫技，而是让对齐这件事更容易被感知。

文件拖到格子上方时也会有反馈，但我特意把它做得很弱。它只需要告诉你 「这里可以放」，不应该一直抢注意力。

我比较喜欢这种设计：功能确实存在，但平时不大声提醒你它的存在。

▍做得更多，不一定更好用

独立做产品很容易陷入一个节奏：有人提了一个想法，就想赶紧做上去；看到别的软件有一个功能，也会担心自己是不是缺了什么。

我前一段时间就有点着急。

结果是功能增长得很快，但有些地方只是 「先做出来了」。之前的待办和随记就是这样，入口很多，信息层级却不够清楚，视觉和交互也没有真正整理好。说实话，那时候连我自己都不太想用。

后来我停下来，把这两个格子从布局、字号、间距、选中状态，到详情编辑、拖动排序和批量操作重新梳理了一遍。

这个过程让我重新确认了一件事：只有我自己长期使用起来舒服的东西，才适合交给其他人。

用户反馈当然重要，但把每条反馈都立即变成功能，不一定是在尊重用户。产品需要有边界，也需要克制。有些建议我会尽量实现，有些和整体方向确实冲突的，只能抱歉地放下。

我希望 DeskBox 最后是一个简单、好用的工具，而不是一个什么都能做、但每件事都做得不够舒服的工具。

▍轻量不是少几个按钮

一个长期放在桌面上的应用，性能本身就是功能。

早期把所有功能格子打开后，我的电脑上内存占用大约在 140MB。音乐格子还出现过连续播放和切歌后，内存不断增长的问题。反复切换语言、明暗模式、材质和透明度，也会留下没有及时释放的资源。

后面我重新整理了窗口生命周期、定时器、图片解码、图标缓存、主题刷新和事件订阅。现在在相同的日常测试环境里，所有功能格子同时打开，内存基本稳定在 50MB 左右。

不同电脑、不同图片和文件数量下的结果肯定不完全一样，但我的目标很明确：当用户没有操作 DeskBox 时，它应该知道安静下来。

轻量不等于界面简陋，也不等于少用新的系统能力。它更应该意味着，不做无意义的持续刷新，不留下不再使用的资源，也不为了一个小效果引入很重的东西。

▍它适合谁，也不适合谁

DeskBox 目前主要面向 Windows 11，我也把 Windows 11 作为主要测试环境。

它比较适合习惯把临时文件放在桌面、希望常用文件夹随手可见，或者想在桌面保留轻量待办和随记的人。

它不适合需要云同步、多人协作、复杂项目管理或完整知识库的用户。待办、随记、天气和音乐都刻意保留了边界，它们不会替代专业应用。

另外需要特别说明：把文件拖入「收纳格子」 时，文件会真实移动到对应收纳目录；如果只想查看现有目录而不改变位置，应该使用 「文件夹映射」。

DeskBox 仍然是一个由我独立维护的早期产品，不同显示器、系统缩放和桌面习惯下，也可能还有我没有覆盖到的问题。

▍写在最后

Windows 给了我们一张桌面，却没有真正教我们怎样整理它。

我做 DeskBox，不是想替换桌面，也不是想重新发明一套文件系统。我只是希望在已经用了很多年的 Windows 桌面上，补一点秩序。

文件有地方放，临时内容有地方记，待办能看见，天气和音乐可以顺手处理。需要的时候把格子叫出来，处理完之后，再把注意力交还给正在做的事情。

一点点就够了。

DeskBox 已经开源，GitHub 提供免费安装包。无广告免费使用。

GitHub：https://github.com/Tianyu199509/DeskBox

官网：https://deskbox.fun/

/产品推荐/