Mylar3 介绍与选型指南

目标：回答「Mylar3 是什么、能做什么、值不值得选」三个问题，并给出 Mylar3 与 Kapowarr、ComicStreamer、LazyLibrarian 的量化对比。本篇为纯联网溯源篇，全部数据来自官方仓库与官方文档站，采集日期 2026-10-28；本篇不含本机安装实测，可复现的安装与运行证据见 《Mylar3 0.8.3 Ubuntu 22.04 安装指南》 等实测篇目。

一、环境信息

本篇是认知与选型文档，不涉及本机部署，但为便于读者核对，先列出取证口径与版本基线：

• 调研对象：Mylar3（GitHub 仓库 mylar3/mylar3）
• 版本基线：v0.8.3（官方最新稳定版，发布日 2025-08-17）
• 信息采集日期：2026-10-28（星数、提交数、发版记录均为当日快照）
• 取证来源：GitHub 仓库主页、releases.atom、commits/master.atom、仓库内 README.md 与 requirements.txt、官方文档站 mylarcomics.com
• 对比对象：Kapowarr（Casvt/Kapowarr）、ComicStreamer（beville/ComicStreamer）、LazyLibrarian（LazyLibrarian/LazyLibrarian，主仓库在 GitLab）
• 单位与口径：Stars/Commits 取 GitHub 仓库页当日报值；版本取 GitHub Releases 的 tag；「最近提交」取默认分支提交 Atom 源的首条时间

💡 说明：GitHub API 有限流，本文的量化数据全部从仓库页面 HTML 与官方 Atom 源读取，未直接调用 API。读者复核时请注意这些数字会随时间变化，复核应以当日页面为准。

二、软件概述

Mylar3 是 Mylar 的 Python 3 分支，定位是「自动化漫画（cbr/cbz）下载器 + 库管理服务」。它维护一份系列（series）订阅清单，按周期去索引器/直链站点搜索新刊，命中后把下载任务交给下载客户端，下载完成再做重命名、移动、写元数据，最终归入本地漫画库。

官方 README 对它的定义是："Mylar is an automated Comic Book (cbr/cbz) downloader program for use with NZB and torrents." 仓库描述则是 "The python3 version of the automated Comic Book downloader (cbr/cbz) for use with various download clients."（采集日期 2026-10-28）。

从工程视角看，Mylar3 属于「带 Web 管理界面的后台守护服务」：进程常驻、有 SQLite 数据库、有定时任务调度、有对外 HTTP 接口与 API。它不像纯命令行工具那样一次性执行完就退出，因此部署时必须考虑服务托管（systemd）、日志轮转与数据目录持久化。

💡 技术拓展：同类的漫画自动化工具在「元数据来源」上有两条典型技术路线——在线元数据中心（ComicVine、Metron 等，信息全、可跨库匹配，但依赖外部 Key 与配额）与本地标签解析（读 ComicRack/ComicTagger 写入的 ComicInfo.xml，无外部依赖，但要求文件已带标签）。Mylar3 走的是前者（ComicVine，且必须自带 API Key），ComicStreamer 走的是后者。选型时先确认自己的库是否已带标签，再决定走哪条路线。

三、核心架构

Mylar3 的代码结构很集中：根目录 Mylar.py 是入口（参数解析、启动顺序、备份、维护模式），mylar/ 包承载业务逻辑，data/ 放静态资源与模板，lib/ 放随包内置的第三方组件，requirements.txt 声明外部依赖。

/opt/mylar3
├── Mylar.py               # 入口：参数解析、启动、备份、维护模式
├── requirements.txt       # 外部 Python 依赖
├── mylar/                 # 业务逻辑包
│   ├── webserve.py        # CherryPy 路由与页面/接口实现
│   ├── config.py          # 配置项定义、读写 config.ini
│   ├── __init__.py        # 启动序列、调度器
│   ├── weeklypull.py      # 周榜抓取
│   ├── search.py          # 索引器/直链搜索
│   ├── PostProcessor.py   # 下载后处理（重命名/移动/元数据）
├── data/                  # 模板、静态资源、imprint 映射
└── lib/                   # 内置组件（含 ComicTagger 相关代码）

核心运行链路可以概括为五段：

1. 订阅与调度：用户把系列加入 watchlist，APScheduler 按 search_interval（默认 1440 分钟，v0.8.3 起由 360 调整为 1440）触发搜索。
2. 搜索与挑选：通过 Newznab/Torznab 索引器、32P、GetComics 等直链站点匹配期号，按质量、大小、发布时间排序挑选。
3. 下发下载：按 nzb_downloader / torrent_downloader 配置把任务交给 SABnzbd、NZBGet、Blackhole 或某款 BT 客户端。
4. 后处理：下载完成后按 folder_format / file_format 重命名、移动，并可调用内置 ComicTagger 写元数据、生成 series.json。
5. 对外服务：CherryPy 提供 Web 界面、OPDS 与可选的 REST API（形如 /api?cmd=getVersion&apikey=<API Key>）。

技术栈与关键依赖（摘自仓库 requirements.txt，采集日期 2026-10-28）：

存储层是单文件 SQLite（数据目录下的 mylar.db），没有独立数据库服务，这一点决定了它的部署门槛很低：装好 Python 依赖、给一个可写数据目录即可跑起来。

💡 技术拓展：漫画库管理类工具的存储方案常见三种——SQLite 单文件（零运维、单机、备份就是拷文件，但并发写弱）、PostgreSQL/MySQL 服务端（多人并发、可远程，但要多维护一个服务）、纯文件系统 + 元数据文件（无数据库，靠 ComicInfo.xml 索引，迁移最省事但检索能力弱）。Mylar3 采用 SQLite，适合单机自托管；如果要做多人共享库，应优先评估后两类。

四、功能特性

Mylar3 的功能面覆盖「找刊 → 下载 → 整理 → 通知 → 对外提供」的完整链路。下表按能力域归纳，并标注外部依赖——这是选型时最容易忽略的部分：功能存在不等于开箱可用。

几个容易被宣传语掩盖的限制，选型时必须纳入判断：

• ComicVine API Key 是硬前置：没有 Key 时启动日志直接报错，添加系列会失败（本机实测回显见安装指南「六、安装后验证」），不是「功能退化」而是「加不了库」。
• 元数据体系偏英文漫画：ComicVine 的刊号、出版社、story arc 数据以美漫为主，中文/日漫体系匹配度低。
• 直链站点随时可能失效：GetComics 一类站点有 CloudFlare 质询，v0.8.3 的发布说明里仍在对 403 返回做告警增强，说明这条链路本身不稳定。
• 周榜计算存在年份硬编码缺陷：源码在多处按 2024/2025 做特判，2026 年运行时周榜任务会抛异常（本机实测已复现，详见命令与运维篇的排障小节）。
• 维护类子命令在 Python 3.12 下有兼容问题：-fs、-xj 会因 str/bytes 混用报错（本机实测），主服务功能不受影响。

五、官方快速开始（文档溯源，未在本机复现）

官方 README 给出的源码安装路径非常短：克隆仓库 → 装依赖 → 跑入口脚本。下面命令逐行来自官方 README 与仓库 requirements.txt 的说明，属于文档溯源，未在本机复现；可直接执行的实测版本（含 Python 3.12、systemd 托管、反向代理）见安装指南篇。

# 1) 获取源码（官方 README 指定方式）
git clone https://github.com/mylar3/mylar3.git /opt/mylar3

# 2) 建虚拟环境并装依赖（requirements.txt 为官方声明）
cd /opt/mylar3
python3 -m venv venv
./venv/bin/pip install -r requirements.txt

# 3) 启动（默认监听 8090）
./venv/bin/python Mylar.py

启动后浏览器访问 http://<服务器IP>:8090/，首次进入需要先填 ComicVine API Key 才能添加系列。官方文档站把安装、备份、API 分成三条主线（docs/installation/*、docs/guides/auto_backups、docs/api/*），版本更新说明则集中在 GitHub Releases。

⚠️ 注意：上述命令未包含运行用户、数据目录、服务托管与开机自启，直接照抄会得到「前台进程 + 数据落在代码目录」的原型状态，不适合长期运行。生产化部署请按安装指南篇逐节执行。

六、适用场景与限制

适合的场景：

1. 长期追更美漫连载：watchlist + 周榜 + 自动搜索是它的主战场，配合 SABnzbd/NZBGet 可以做到「新刊发布后自动入库」。
2. 已有漫画库需要补缺与规范化：扫描本地库、按缺失期号补齐、统一重命名与写元数据，是比手工整理更省事的路径。
3. 按故事线收集：Story Arc 追踪对「想按大事件（如 Civil War）收全」的用户很实用，这是纯下载器不具备的能力。
4. 单机自托管、低运维预算：SQLite + 单进程，备份就是拷 mylar.db 与 config.ini，没有额外中间件。

不适合的场景：

1. 中文/日漫为主的库：ComicVine 元数据覆盖不到，刊号与卷册体系也对不上。
2. 不愿申请第三方 API Key：没有 ComicVine Key 连系列都加不进去。
3. 只想在线阅读/串流：Mylar3 是「下载与整理」工具，阅读体验不是它的目标；纯阅读/串流应另选阅读服务器。
4. 要求高并发多人使用：SQLite 单写者模型 + CherryPy 默认 backlog 5（本机 ss 实测），面向个人/小团队而非多租户。

前置条件清单（选型评审可直接对照）：

七、同类选型对比

选取四个常被放在一起讨论的项目做量化对比。数据口径统一为「GitHub 仓库页 + Releases Atom 源，2026-10-28」，LazyLibrarian 的主开发在 GitLab，额外标注 GitLab 提交时间。

关键差异解读：

• Mylar3 vs Kapowarr：两者都用 ComicVine，但侧重不同。Mylar3 强在「追连载」——周榜、story arc、失败重试、多下载客户端；Kapowarr 强在「按卷建库」——*arr 风格的批量搜索/手动搜索、导入现有库、下载后解包重命名。如果目标是「每周自动追新刊」，Mylar3 的功能面更对口；如果目标是「把已有收藏按卷管理起来」，Kapowarr 的交互更现代。需要接受的事实是：Mylar3 自 2025-08-17 后没有新版本，Kapowarr 在 2026-09 仍在发版。
• Mylar3 vs LazyLibrarian：不是同赛道。LazyLibrarian 管的是作者/图书/有声书，元数据源是 Hardcover、OpenLibrary、GoodReads；它可以下载「书」，但不理解刊号、卷册、story arc。拿它管漫画会在元数据与期号匹配上持续踩坑。
• Mylar3 vs ComicStreamer：ComicStreamer 是「已整理好的库」的对外服务层——REST API + 网页浏览 + 分页取图，元数据靠文件内的 ComicInfo 标签；它不搜索、不下载。项目最后提交停在 2014-11-26，README 自述仍是 ALPHA 阶段、依赖 Python 2.7，新环境不建议采用。

「如果…则…」选型建议：

八、版本与社区活跃度

Mylar3 的发版节奏可以直接从 releases.atom 读出。下表列出近两年全部 10 个 tag 及其发布时间（采集日期 2026-10-28）：

据此可以算出两个对选型有用的事实：

• 历史节奏：2023-08-18 至 2025-08-17 共 24 个月发了 10 个版本，平均约 2.7 个月一版，属于「小步快跑」型维护。
• 当前状态：截至 2026-10-28，距最近一版 v0.8.3 已 14 个月，默认分支最近提交同样停在 2025-08-17（commits/master.atom）。这说明项目进入低频维护期，而非停止——代码仍在、issue 仍在收，但不要预期「新功能很快落地」。

社区入口方面，官方 README 指向 Discord、GitHub Issues、官方论坛与 IRC；文档站 mylarcomics.com 提供安装、自动备份、API 三块文档。对自托管用户而言，这意味着遇到问题时「官方文档 + issue 检索」是主要支持渠道，没有商业支持兜底。

⚠️ 注意：低频维护期的项目要额外评估「上游服务变更」风险。Mylar3 的关键链路依赖 ComicVine、GetComics 与各家索引器，这些外部站点一改接口，工具就可能失效；选型时应把「能否自行改代码/换源」纳入运维能力评估。

九、参考链接