Audiobookshelf

一套有声书可能有几十个音频文件，听到哪一章、还剩多少内容，靠文件名和普通播放器管理起来很费心。 换到另一台设备，又得回忆上次停下的位置。 Audiobookshelf 可以把有声书和播客整理成自己的媒体库，为每位用户保存收听进度，并在设备之间同步。

把音频文件整理成有书名和章节的书架

Audiobookshelf 是开源自托管有声书与播客服务器。 你负责提供音频文件和运行服务的设备，它负责展示媒体库、播放内容，以及保存用户的收听状态。 网页端可以使用，项目也提供 PWA 与移动端应用入口。

整理音频时，书名、作者和章节信息会影响后续浏览体验。 项目支持从多个来源获取元数据与封面，提供章节编辑和章节查询，还能将多个音频文件合并为一个 M4B 文件。 对已经按章节拆分的有声书，这些功能可以减少在多个文件之间寻找内容的麻烦。

官方说明特别强调文件夹结构、命名和音频元数据的重要性。 导入之前，值得对照媒体库文档检查现有目录，避免把多个作品混在难以辨认的文件夹中。 建议从少量书籍开始，确认作者、作品和章节识别正确，再逐渐扩大书库。

图片来自官方仓库中的演示书库截图，展示书架与播放控件。

进度跟着账号走，家人可以各听各的

Audiobookshelf 支持多用户和自定义权限，并为每位用户保留进度。 家人可以访问同一套媒体收藏，分别记录自己的收听位置。 从电脑换到手机时，通过支持进度同步的访问方式继续使用同一账号，可以接续之前的内容。

选择客户端时，需要把设备条件考虑进去。 截至 2026 年 11 月 1 日核对的官方 README，Android 和 iOS 应用仍标注为 beta，iOS 的 TestFlight 测试名额已满。 准备主要用 iPhone 收听的人，可以从网页端或 PWA 评估日常使用方式，并关注官方后续公布的客户端入口。

项目还提供基础电子书支持，包括 EPUB、PDF、CBR 和 CBZ 等格式，以及发送电子书到设备的功能。 如果主要需求是有声书和播客，这些阅读功能可以作为补充；整理大量电子书时，仍应结合自己的书目管理习惯选择工具。

播客订阅也能留在自己的服务器里

Audiobookshelf 可以搜索和添加播客，下载节目，并设置自动下载。 这样既能管理手动保存的音频，也能持续收集正在追听的播客内容。 它还支持为有声书和播客开放 RSS 源，方便按需要连接其他支持 RSS 的播放工具。

自动下载会持续使用存储和网络流量，部署时应给播客目录留出空间，并定期检查保留了多少节目。 向其他设备开放 RSS 时，也要核对访问范围，避免把私人音频集合分享给无关的人。 媒体库中的书籍和节目需要来自自己有权保存、使用的来源。

Docker 部署要把媒体和服务数据分开保存

官方 Docker 文档推荐通过 Docker 运行，并提供 Docker Compose 示例。 常见部署会使用以下目录映射。

容器目录	存放内容
/config	SQLite 数据库与数据库迁移脚本
/metadata	图书元数据、封面和作者图片、日志、备份
/audiobooks	自己提供的有声书文件
/podcasts	播客媒体文件

这些挂载目录需要各自独立，避免把一个挂载目录放进另一个挂载目录内部。 其中 /config 必须位于运行 Audiobookshelf 的同一台机器上，官方明确要求不要通过网络访问另一台 NAS 上的数据库文件，以避免性能与数据库损坏问题。 媒体文件和服务数据库的存放方式应分别安排。

官方 Compose 示例将主机 13378 端口映射到容器 80 端口。 需要从外网访问时，可以参考官方反向代理文档，同时配置加密连接与账号权限。 Audiobookshelf 需要 WebSocket 连接，反向代理也必须正确支持这一连接方式。

备份范围要包括音频本身

项目提供元数据备份与自动每日备份功能。 音频收藏仍需要单独安排备份，尤其是自己整理过章节、封面和元数据的文件。 服务设置、媒体信息及原始音频都有恢复价值，升级或更换硬盘之前，应检查这些内容是否有可用副本。

软件开源免费，自托管所需的服务器、硬盘、带宽和日常维护由使用者承担。 已有 NAS 或家庭服务器、手里积累了合法音频收藏的人，可以从一套有声书和一个播客订阅开始，检查识别、播放、进度同步和备份是否符合自己的习惯。 这些环节安排好之后，再逐步迁入长期收藏，会更容易维护。

官方入口

• 项目仓库与客户端说明
• Docker 部署文档
• 媒体库目录与命名说明
• 反向代理文档