2026-02-23 21:25:05
前些时间提到，我的群晖 NAS 数据被套件误删了。由于是第三方套件造成的，即便我之前使用的是正版群晖硬件，也不可能就此向官方讨个说法。不过，我仍庆幸群晖有着强大的应用生态，能借助多种工具的协同配合完成重要数据的备份。例如，我通过 Hyper Backup 对 Docker 数据文件夹做了增量备份，又用 CloudSync 将这些备份同步到了云端。当本地数据意外丢失时，这些云端的备份全部得以幸免于难。
可换用飞牛的 fnOS 作为 NAS 系统之后，这套备份组合也随之失效。
fnOS 无论是界面、应用、生态还是移动端 APP ，都很符合我现阶段对一个 NAS 系统的基本需求。唯一美中不足的地方，就是它的备份功能。
作为 NAS 系统，其备份功能仍显不足。即便是迭代至正式版，它支持的备份方式也依旧有限。而且在实际使用过程中，备份到百度网盘的数据还会因为体积太大而经常上传失败。
我本想着，既然现在的 fnOS 备份不方便，说不定后续的更新迭代会优化这一块，要不就先放一边，等下次想起来再说。可谁曾想，飞牛于近日被爆出存在超高危的 0day 漏洞。
这可把我吓了一跳。好在我一直通过 VPN 访问家庭网络，从未将 NAS 公开至公网，仔细检查后也没有发现病毒。
但要命的是，虽然该问题在系统更新后被修复（？），但是飞牛官方对此次事件采取的却是近乎冷处理的公关方式：既没有第一时间向用户发出明确的风险预警和紧急防护指引，也未做任何醒目的升级提醒，更是使用「异常访问风险」、「自身代码疏漏」这类模糊表述淡化问题本质，迟迟不肯正面承认此次漏洞产生的严重危害。
软件存在问题在所难免，承认错误及时处理便是，可飞牛对待此类安全问题却是这般敷衍的态度。我开始重新评估自己对该系统安全性的信任边界。这次的攻击者只是利用漏洞将 NAS 当作肉鸡对外攻击，更现实的担忧在于，若未来攻击直接针对数据本身，后果可能远比此次事件严重。我不希望遇上数据被病毒加密勒索的糟心事，不希望暴露 XP，更不想重新整理一遍动画片……
眼下 NAS 不在身边，我没法立刻更换系统，只能先决定即刻采取备份措施，避免后续出现任何数据安全意外。
但离了群晖的 Hyper Backup 和 Cloudsync 的助阵，有什么简单的方法，可以实现定时的增量备份，并将备份数据保存到云端呢？
这就需要请 Backrest 登场了。
在介绍 Backrest 之前，有必要先引入一个几乎被所有备份方案反复提及的原则——「3-2-1 备份原则」。
所谓「3-2-1 原则」，是指在进行文件备份时，需要做到：
3：至少保留 3 份完整的数据副本，防误删。例如：
2：存储在 2 种不同的介质上，防硬盘损坏。例如：
1：存储 1 份备份在异地，防勒索病毒、极端物理灾害。例如：
在合理执行的前提下，可以最大限度降低数据丢失的风险。
可是，即便我们有意愿按「3-2-1 原则」执行备份，却需要面对另一个残酷的现实：如今机械硬盘的价格，已不是常人所能轻松负担的了。
我 2022 年 3 月购买的一块全新国行 8T 西数 HC320 的价格为 995 元。
但是！细心的小伙伴们应该已经注意到了，在「3-2-1 原则」的示例中，几乎每一步都可以将数据备份到「云存储」上。而云存储的价格，远比同等容量的硬盘便宜。
除了网盘，还有 COS、OSS、S3、B2 等一众云存储服务可供选择，价格都比购买实体硬盘要实惠，我们便可以考虑直接将数据备份到一个乃至多个不同的云端，以较低的成本满足「3-2-1 备份原则」的要求。
最终，我决定使用 Restic 作为我备份体系的核心。
Restic 是一款优秀的命令行备份工具，以快速、安全、高效著称。它支持：
但由于缺乏图形界面与调度管理功能，仍需配合脚本与 cron 实现自动化。对不想折腾这些东西的我来说，使用起来非常痛苦。
Backrest 正是在这一背景下登场的。作为一款专为简化 Restic 备份管理而设计的 Web UI 和编排工具，Backrest 通过直观的图形界面包装了 Restic 的命令行功能，并补齐了任务调度、状态监控与集中管理等关键功能，让复杂的 Restic 备份操作变得简单易行。
借助 Backrest，我们便能使用 Restic 实现一套可以长期稳定运行、也更容易被维护的备份方案。
在正式开始之前，我们需要先思考一个很严肃的问题：
我们应该备份哪些数据？
备份并不是简单地把所有文件原封不动地复制一份。操作系统、软件包，甚至容器和镜像，本质上都属于可重建资源，只要环境还在，花一点时间就能重新部署。真正值得被长期保存的，是那些随着使用不断产生、积累，且一旦丢失就很难恢复的数据。
从实际使用场景来看，以下几类内容通常应当作为备份的重点：
高恢复成本数据
例如游戏资源、音乐等。严格意义上说，这些文件并非完全不可再获取，但一旦涉及到命名规范、目录结构、封面整理和元数据获取，它们的恢复成本就不再只是「重新下载」那么简单。
相对应地，也有一些内容并不适合作为常规备份对象：
通过这种取舍，将备份的重点从「尽可能多地保存数据」，转变为「只保存真正重要的那一部分」。不仅能有效控制备份体积和成本，也可以让后续的备份与恢复过程更加清晰、可控。
这里以 Docker Compose 安装 Backrest 为例。
首先，需要在宿主机上创建好必要的数据文件夹，用于存放程序数据、配置、缓存和临时文件：
mkdir -p data config cache tmp rclone随后新建 compose.yml 文件，填入以下内容：
services:
backrest:
image: garethgeorge/backrest:latest
container_name: backrest
hostname: backrest
volumes:
## 程序数据文件夹
- ./data:/data
- ./config:/config
- ./cache:/cache
- ./tmp:/tmp
- ./rclone:/root/.config/rclone # 挂载 rclone 配置（使用 rclone 远程时需要）
## 挂载本地备份路径
- /vol1/1000/media:/vol1/1000/media
- /volume2/docker:/volume2/docker:ro
environment:
- BACKREST_DATA=/data
- BACKREST_CONFIG=/config/config.json
- XDG_CACHE_HOME=/cache
- TMPDIR=/tmp
- TZ=Asia/Shanghai
ports:
- "9898:9898"
restart: always有几点需要注意：
ro 权限（如上例 /volume2/docker）。9898 用于访问 Backrest Web UI，如果通过反代访问，也可以不映射到宿主机。访问 IP:9898 启动 Backrest。Backrest 会根据浏览器语言自动切换显示语言，并弹出设置。你需要先为这台机器上启动的 Backrest 服务设置一个唯一的 实例ID，例如 my-nas ，用以区分多个 Backrest 服务。
接着，设置身份验证。如果你的 Backrest 只计划在内网中使用，那么可以不设置用户，并禁用身份验证。但如果是公开的服务，请务必设置好登录用户和高强度密码，并确保未勾选 禁用身份验证 选框，以启用身份验证功能。
鉴于公开服务可能带来的不可预测因素，建议即便是内网，也使用强密码认证身份，并在配置完毕后关闭 Backrest 服务的端口。
你应当尽可能自行阅读 backrest 官方指南 (英文) 以了解如何配置仓库，或者查看 Restic 文档 (英文) 了解更多有关仓库的信息。
不过我也没看过，诶嘿但本文演示时所使用的 Backrest 1.11.2 版本已原生支持中文界面，因此在实际配置过程中，基本可以做到无需额外查阅文档即可完成操作。
点击左侧的 「添加仓库」 按钮，新建一个 Restic 仓库。该仓库即为备份数据的最终存放位置，后续所有备份任务都可以将其作为统一的备份目的地。
首先，为其指定一个「仓库名称」。该名称仅用于 Backrest 内部识别不同存储库，例如区分本地仓库与云端仓库，本身并不影响实际的存储路径或数据结构。仓库名称创建后无法修改，因此建议在命名时保持清晰与可区分性。
而最关键的 「仓库 URI」，需要严格按照所选存储方式对应的 URI 格式填写。无论是本地路径、S3 对象存储，还是通过 rclone 访问的远程存储，只有格式正确，Backrest 才能成功连接并初始化仓库。
例如：
/vol1/1000/backups/Restics3:my-backup-bucket/Resticremote-name 为 rclone config 中定义的远程名称，Restic 为仓库存放的子目录。
「仓库密码」 用于对 Restic 仓库中的所有数据进行加密。Restic 采用端到端加密设计，所有备份内容在写入存储库之前就已经完成加密，云端或远程存储只会保存加密后的数据本身。可以直接使用 Backrest 自动生成一段强度较高的随机密码，通常已满足安全需求。但如果有统一的密码管理策略，也可以自行指定符合习惯的密码。此外，Restic 也支持通过环境变量（如 Restic_PASSWORD、Restic_PASSWORD_FILE 等）提供密码，方便在自动化或无交互环境中使用。
需要特别注意的是：该密码无法被找回或重置。一旦密码遗失，即使仓库文件仍然完整存在，也将无法再解密其中的任何数据。因此，应将仓库密码视为与数据本身同等重要，并妥善保存。建议使用密码管理器进行存储。
下方的 「自动解锁」 选项用于在执行清理（forget）和修剪（prune）操作前，自动处理仓库锁定文件。在单实例、单设备使用的情况下通常不会用到，但如果同一个仓库被多个设备或实例同时访问，开启该选项反而可能带来安全隐患，因此默认保持关闭即可。
环境变量和命令参数（Environment & Flags）一节，本地仓库或通过 rclone 访问的常见云存储，大多数情况下可以留空。只有在使用对象存储、需要自定义认证方式，或对 Restic 行为有特殊需求时，才需要进行配置。
这里粘贴一段 AI 的见解，不一定准确。你可以在有需要时详尽地向 AI 发问、或阅读官方文档，并在正式将仓库投入使用前大量测试。
用于向 Restic 传递环境变量，最常见的用途是：
Backrest 会在执行 Restic 命令时，把这里填写的变量一并注入到运行环境中。常见示例包括：
S3 / 兼容对象存储
AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYAWS_DEFAULT_REGIONBackblaze B2
B2_ACCOUNT_IDB2_ACCOUNT_KEYRestic 通用
Restic_PASSWORD（仓库密码，不想写在仓库配置里的话）另外一个比较实用的小细节是，这里 支持引用父进程中的环境变量，例如：
AWS_SECRET_ACCESS_KEY=${MY_AWS_KEY}这在 Docker / systemd 环境中非常好用，可以把敏感信息只放在宿主环境里，而不是写死在 Backrest 配置中。
对应的是 直接追加到 Restic 命令后的 flags，属于更偏高级/进阶的用法。适合以下场景：
常见例子有：
限制并发、降低 IO 压力
--limit-upload 20480指定缓存目录
--cache-dir /data/Restic-cache某些 S3 兼容存储需要关闭 HTTP/2
--option s3.disable-http2=true这些参数 不会影响 Backrest 本身，只会在它调用 Restic 时生效。
日常执行备份时，Restic 的工作机制是：
backup：只往仓库里追加新数据块，从不删旧数据snapshots：只是这些数据块的「索引」，方便按时间点恢复forget：删除的是快照记录本身，不会立刻删除底层数据还需配合 prune 来完成最后的空间回收工作。prune 意为修剪、精简，在 Restic 中，prune 用于删除不再使用的数据块。具体流程可以概括为：
但由于 prune 需要遍历仓库索引，并对大量数据块进行读写、校验和重组，这一过程相对耗时且对存储 I/O 压力较大，尤其是在仓库规模已经不小、或使用对象存储的情况下更是如此。因此，Restic 官方文档并不建议在每次备份完成后都立刻执行 prune，而是推荐将其作为一项低频的维护任务，定期运行即可——例如每周一次，或每月执行一次清理。既能有效回收空间，又不会对日常备份造成额外负担。
Backrest 自然是将 prune 也做成了一个可视化的定时任务。
你只需要在初始化仓库时，完成三件事：
设置最大未使用比
对应 Restic 的 --max-unused 参数，单位是百分比。
顾名思义，这个数字代表允许仓库中未使用内容所占的最大百分比：
对个人 NAS 来说，保持默认的 10 一般已经足够。
选择 Schedule Type（何时执行）
这决定 prune 自动运行的方式，有以下几种：
Disabled：禁用自动执行，只在手动点击「运行」时才会清理Interval (Hours)：每隔 N 小时跑一次Interval (Days)：每隔 N 天跑一次Cron：使用标准 cron 表达式自定义时间点对个人 NAS 来说，更推荐选择 Interval (Days)，每 7 天运行一次；或选择 Cron，设置每周/每月指定时间段（比如无人使用 NAS 的凌晨）运行。
Cron Expression 与 Reference Clock
当选择 Cron 时，会出现：
Cron Expression（Cron 表达式）：
0 0 1 * *：表示「每月 1 日 0 点 0 分」0 3 * * 0
表达式可以直接询问 AI 获取。
Reference Clock（参考时间）：
Local：按服务器本地时区UTC：按 UTCLast Run Time：多用于「间隔」调度，基于上一次实际运行的时间继续往后算综合起来，一个相对通用、比较稳妥的配置是：
10（默认）Cron
0 3 * * 0（每周日凌晨 3 点自动清理）Local
这样，Restic 就会在通常不怎么用机器的时候自动执行 prune，对仓库进行「垃圾回收 + 瘦身」。既不影响日常使用，又能长期把磁盘空间控制在一个相对合理的范围内。
这一项对应的是 Restic 的 check 操作，用于验证仓库中数据的完整性。
验证数据占比
这里填写的是一个百分比，用来控制每次检查时抽查多少数据。
100%：每次检查都会完整扫描并校验整个仓库，最安全，但耗时和带宽开销最大5%、10%）：只随机抽查一部分数据块，能在较低成本下发现大多数潜在问题对于已经稳定运行的仓库，一般不需要每次都全量校验，定期抽查即可；而在刚迁移仓库、存储后端不太可靠（比如部分对象存储）时，可以适当调高比例。
在大多数使用场景下，这一部分完全可以保持默认。Backrest 已经为常见环境选择了相对保守、稳定的配置，除非你对系统资源调度或自动化流程有明确需求，否则无需在这里折腾。
这里同样粘贴一段 AI 的见解，仅供参考。
高级设置可以为备份任务指定运行时的 IO 与 CPU 优先级，用于控制 Restic 在系统中的「存在感」。
IO_DEFAULT 表示不做额外干预，由操作系统自行调度。CPU_DEFAULT 同样表示使用系统默认策略。在以下场景中，这些选项才可能派上用场：
否则，保持默认，Restic 本身已经足够克制。
Hooks 用于在备份生命周期的特定阶段执行自定义脚本，例如：
典型使用场景包括：
dump
prune 或 check 前后执行清理或校验操作对于只想安稳备份数据的用户来说，这一功能并非必需；但如果你有自动化流程需求，Hooks 提供了非常大的扩展空间。
以创建一个本地仓库为例。
仓库详情
local
/vol1/1000/backup/mikusa
********（自动生成强密码）Environment & Flags（参数变量）
Prune（定期修剪）
10（默认）Cron
0 3 * * 0（每周日凌晨 3 点自动清理）Local
Check（数据校验）
10（视数据重要程度和体积而定）Cron
0 2 1 * *（每月 1 日凌晨 2 点校验）Local
Advanced（高级设置）
点击左侧的 「添加调度计划」 按钮，新建一个 Restic 计划。必须先配置好仓库，才能新建调度计划。
这里需要注意的事项与创建 Restic 仓库时基本一致。例如，计划名称必须唯一，且创建后无法修改，主要用于区分不同的备份任务。此外，虽然可以直接选择已创建的仓库作为备份目标，但单个计划只能指定一个仓库；若需要同时备份至多个目标，则需分别创建多个计划。
不过，一个仓库是可以供多个备份计划使用的。在 Restic 中，多个备份计划共用一个仓库时，去重是以「数据内容」为单位进行的，而不是以「计划」或「路径」为单位。即使多个计划备份了相同的文件，这些文件的数据块在仓库中也只会存储一份。因此，即使不同计划备份了大量重叠数据，仓库体积也不会线性增长。
我一开始忽视了「数据去重」的含义，于是在同一存储库里按路径创建了很多仓库……
你可以参考 Restic 文档 (英文) 了解更多信息。
路径
至少添加一个要备份的路径，可以是目录，也可以是文件。Restic 会把这些路径当作备份入口，在快照里保留原本的目录结构。路径也可以在界面中直接选择，避免手动输入错误。
排除规则
用来排除不需要备份的路径或文件模式，语法与 Restic 的 --exclude 相同。可以使用排除规则把缓存、临时文件、日志等剔出去，减小仓库体积、提升备份速度。
例如：
*.tmp ：排除所有临时文件/home/*/.cache ：排除用户缓存目录/var/log ：排除大量滚动日志
这一栏是区分大小写的，在类 Unix 系统中需要特别注意这类问题。
排除规则（不区分大小写）
与上面类似，但匹配时不区分大小写，对 Windows 等环境更友好。比如填写 *.log 时，会同时匹配 .log, .LOG 等。
视数据的重要程度，可手动、按每时/每天、或 Cron 设置备份频率，基本上与创建仓库 prune 时的原理一致，就不再赘述了。
如果没有特别复杂的需求，比较常见的配置是：
Cron
0 2 * * *（每天凌晨 2 点）Local
但这块的 UI 是不是有点问题？强迫症受不了。
保留策略（Retention Policy）对应的是 Restic 的 forget 规则，用于控制旧快照的保留。
可选项有：
By Count：按数量保留，比如只保留最近 N 个快照。
By Time Period：按时间维度保留，是最常用、也最直观的一种。
该模式下每个字段的意思是：
Hourly：每小时最多保留多少个快照Daily：每天最多保留多少个快照Weekly：每周最多保留多少个快照Monthly：每月最多保留多少个快照Yearly：每年最多保留多少个快照Latest (Count)：无论时间如何，始终至少保留最近 N 个快照因此，截图中示例的配置意为：
None：不做自动清理，所有快照都保留。适合短期测试，不推荐长期使用。应该根据数据重要程度、存储空间和恢复需求调整保留策略，例如保留 7 天的日快照 + 6 个月的月快照就已足够日常使用。如果数据本就不是频繁备份，那么也就没必要设置太精细的策略。
计划的「高级设置」也同仓库处一样，没有特殊需求的话可以保持默认。
备份参数对应 Restic backup 命令的额外参数，用于调整备份行为或性能，例如：
--one-file-system：只备份当前文件系统，避免跨挂载点--exclude-larger-than 500M：跳过超大文件--compression max（Restic 0.16+）：提高压缩等级，换取更小体积脚本（Hooks）则可以在备份生命周期的不同阶段执行自定义脚本或通知，支持多种 hook 触发点（如 before-backup, after-backup, on-error 等），具体用法可以参考官方 hook 文档。例如：
现版本的 Backrest 已原生支持 TG 通知，不用自行编写脚本。只需在 Hooks 处选择 Telegram、确定需要通知的环节，填入 Bot Token 和 Chat ID，再参考官方模板设置一下通知文本，就能知道备份有没有正常执行了。
我的模板如下：
📦 备份任务通知
任务名称: .Task }}
执行时间
事件类型
仓库 ID
计划 ID if .Error -}}
❌ 任务执行失败
错误信息 else -}}
✅ 任务执行成功
{{ if .SnapshotStats -}}
📊 备份统计
• 新增数据
• 处理文件数
• 处理数据量
• 执行耗时 秒
{{ end -}}
{{ end }}
From Backrest 自动通知效果大概是这样：
📦 备份任务通知
任务名称: backup for plan "book"
执行时间: 2026-02-18T23:40:39+08:00
事件类型: snapshot end
仓库 ID: baidupan
计划 ID: book✅ 任务执行成功
📊 备份统计
• 新增数据: 0.000 B
• 处理文件数: 4865
• 处理数据量: 533.452 GB
• 执行耗时: 13.3 秒From Backrest 自动通知
让我再举个更实际的例子：使用 openlist 挂载百度网盘，并用 rclone 连接 openlist 提供的 webdav 服务。
先获取个人用户 UID/GID：
# mikusa @ truenas in ~ [11:45:35]
$ id
uid=1000(mikusa) gid=3000(mikusa)准备 .env 环境变量文件，置于 compose.yml 同级路径，填入基础的公共变量：
PUID=1000
PGID=3000
TZ=Asia/Shanghai安装 openlist：
services:
openlist:
image: openlistteam/openlist:latest
container_name: openlist
user: ${PUID}:${PGID}
ports:
- 5244:5244
volumes:
- ./openlist:/opt/openlist/data
environment:
- UMASK=022
- TZ=${TZ}
restart: always
启动后，打开 openlist 添加百度网盘存储，设置挂载路径，如 /baidupan ，并填写刷新令牌。
刷新令牌需在官方的 OpenList Token 获取工具 获取，找到「百度网盘 (OAuth2) 验证登录」并勾选「使用 OpenList 提供的参数」，点击「获取 Token」，将底下的刷新令牌粘贴至 openlist 对应位置即可。
确认当前用户具备 Webdav 相应权限。
在终端中连接 NAS，进入 Backrest 容器内部命令环境：
docker exec -it backrest /bin/sh使用 rclone config 新建 rclone 配置， 添加 WebDav 存储，所需的信息有：
具体流程这里不做演示。
创建完成后，rclone 对应映射文件夹内的 rclone.conf 文件应当有如下内容：
[openlist]
type = webdav
url = http://openlist:5244/dav
vendor = other
user = mikusa
pass = mikusamikusamikusamikusamikusamikusa密码部分是自动加密的，因此会与真实密码看起来不太一样。
使用 rclone ls openlist:// 测试配置是否有误，如有输出即表示正常。例如：
/ # rclone ls openlist://baidupan/mikusa
8753641238 零售机_游戏性能大横评_2026.mp4
842538736 琉璃的宝石/AICL-4796～7.rar
829036840 琉璃的宝石/VVCL-2788～9.rar接着，打开 backrest 创建 Restic 仓库。
假设网盘挂载路径为/baidupan，计划备份到 mikusa/Backup/truenas 内，那就在仓库 URI 一栏填入：
rclone:openlist://baidupan/mikusa/Backup/truenas
如果是多个计划使用同一个仓库，可以考虑勾选自动解锁，否则修剪任务可能会失败。
保存仓库、测试连接成功后，即可新建计划任务使用这个仓库。
你可以先备份一些小文件进行测试，并尝试恢复云端备份文件到本地。待确定一切正常后，再执行大批量备份。
由于上传的都是些经过加密的文件块，体积不大。实测备份约 2T 数据，暂未遇到上传限制问题（具体情况可能因账户与网络环境而异）。唯一可能需要担心的，便是宽带运营商是否会因持续大量的上传而限速了。
以上便是我关于 Backrest 的全部心得了。不同于 Restic 只是一个纯粹的命令行工具，Backrest 本质上是一个常驻运行的 Web 服务，拥有完整的 HTTP 端口监听、用户认证与任务调度能力。为了读取所有需要备份的目录，它在 Docker 中往往需要较高权限，甚至直接挂载宿主机的大量路径。这意味着，一旦 Backrest 本身存在安全漏洞——无论是认证绕过、未授权访问，还是远程代码执行——攻击者能够触及的范围，便远不止备份数据本身。
当然，这并不意味着 Backrest 不值得使用。对于大多数家庭 NAS 场景而言，只要运行在内网环境中，做好基本的隔离与访问控制，风险通常是可以接受的。若你对安全边界有更严格的要求，那么直接使用 Restic + cron 的纯命令行方案，会是更简洁、也更克制的选择。
本文在摸索时期参考了少数派对「3-2-1 原则」的《不想被勒索软件毁掉数据，就按照「3-2-1 原则」来备份文件》，刘一树的《服务器备份 - backrest + rclone + oss》，试验成功、再加上官方推出了中文界面后，便大量依赖 ChatGPT、Gemini、Doubao 等一系列人工智能的解释了。
因而本文 AI 含量较高，如有顾虑，酌情阅读。
2026-01-26 06:00:00
我真是懒到一定地步了，本来想着年末最后一天写完的总结，竟然拖到了今天！让我看看今儿是几号了……唔，看不太清。总之，这篇文章什么时候发布，那就是什么时候写完的！(:з」∠)
下面开始正文！
好久没写所谓的「年终总结」了，因为总觉得现在的我并没有什么值得拿出来「总结」一番的东西。每当启动 Typora、新建好 总结.md，准备在键盘上敲点什么的时候，就只会想起自己日渐隆起的啤酒肚、爬满额头的皱纹，以及不得不向年龄屈服的身体。再回过神来，原本打算记录的灵感火花，转瞬就变成了「工作依旧一事无成，学习仍然毫无建树」这句我连着用了好几年的废话，在文档上闪烁着光标。
唉，去他妈的。不就是没什么本事嘛，只要接受了自己的无能，那我就是无敌的！
姑且来看看博客近一年的成果吧。
今年的博文，内容涵盖滥竽充数的服务器运维、含水量极高的日常记录，以及没有人看的新番点评。
由于几近提笔忘字，为了锻炼不曾有过的写作能力，今年我尝试记录了不少追番报告，但最终看来收效甚微。在反复的字句斟酌中，我的文字水平几乎没有任何提升，我仍旧不擅长这类文章。更糟糕的是，我还变得极度依赖起 AI 来。每写一段，就复制给 AI 检查。
- 帮我看看有没有语病
- 帮我查查看有没有逻辑问题
- 怎么继续往下写，给点 idea
- 你踏喵不要添油加醋啊 kora！
- ……
不只是议论文，就连记录、技术相关的文章，甚至是日常水文，我也全部一股脑发送给 AI 勘误。就这样一来一回，我完成了今年的 17 篇文章。
虽然 AI 给的建议都很中肯，但修改之后，多少还是感觉有些丧失了属于自己的语言风格，即便那些句子确实有毛病……来年的话，要尽量多看几部文学作品，多刷一些鱼太的视频，以期在文字方面精进一点。
而落实到数据上，来看看今年的 Umami 报表。今年博客累计收获了 174K 的访客，带来 212K 的访问次数以及 331K 的浏览量。由于 2023 年没写总结，2024 年的 Umami 数据因为我瞎折腾把数据库炸了……所以，本年度访客和访问量，均较 2022 年有所增长。即便跳出率增加了 3%，但平均访问时长也增加了 5 秒，可喜可贺！
这倒也理所应当，因为这些成绩并不是今年的新文章造就的，而是去年、前年、乃至更早些时候的文章带来的访问量。
可见今年的内容，受欢迎程度甚至不及 3 年前。
必须承认，以前写的文章在现在看来也很有趣。我可真是个小天才！但身为作者，还是有点无法接受这一现实的。今年的水文怎么可能一点作用都没有！于是，我又非常不服输地让 AI 根据我的发文量和访问量绘制了张毫无相关性的图片，企图在两者之间找到一丝关联性。
图表出来，答案就非常明显了：博客访问量根本不受现在的我控制。
我更新，或者不更新
访问量就在那里
不增不减
这是不是意味着，即便未来我不再更新，也可以获得稳定的访问量？这就开始咕咕！
好吧，这个结果我其实也预见到了。早在我找到除「刷机」之外新的流量密码后，我就意识到，只要我继续讨论与「NAS」有关的话题，博客就能稳定地收获源源不断的点赞和访客。可现实情况是，我的 NAS 运行稳定，相关的需求已然饱和，我的空闲时间更不足以支撑我继续钻研有趣的工具……
所以，今年在 NAS 方面的文章，就较前两年少了很多。
但今年也久违地刷了次机。虽然只是参考我曾经的教程，可至少重温了刷机的乐趣，继而憋出另一篇《备用机的养成方法》来。也算是勉强用上了流量密码？
甚至选头图的时候看上了 Google Pixel 9，可后来连备用机都吃灰了，这个想法也便作罢。
再来看看谷歌这边。根据谷歌统计的数据显示，今年获得了约 130K 的新用户，约 230K 的浏览次数，与去年相比都呈下降趋势。但临近年末有一撮特别明显的高峰，不晓得是从哪儿来的。
而从 Search Console 的搜索曝光度来看，今年的点击量走势不错。也可以进一步确定，即便今年我没怎么更新，过往文章的质量还是获得了广大网友的肯定。
突然有点飘飘然起来是怎么回事，嘿嘿，嘿嘿嘿……
说罢博客，姑且来看看今年我都做了些啥。
2025年，在春光乍泄的二月初，为了去未曾谋面的网友家中蹭饭，我来到了杭州。我在下午两点左右到达杭州站，艰难地找到朋友、将行囊放在他的住处后，便直奔计划中的第一站：良渚古城遗址公园。我们原打算用相机记录公园的早春，但由于错估了时间，抵达时已临近闭馆（闭馆六点，但五点半就关门了），禁止入内；天公也不太作美，厚重的云层遮蔽了天空，透不出一丝阳光。我们只好顶着冷风在公园门前闲逛，拍了几张照片，就回去吃饭了。
不要问我为什么喜欢拍树杈，我也不知道，你权当那时的我脑壳有坑。
吃过晚饭，我和朋友商议，明天可千万不能像今天这样空手而归，一定要有所准备。简单讨论之后，决定第二天去动物园拍猴子和长颈鹿，并购入了门票。然后，我们碰上了单双号限行…… 这算是身为十八线小村民缺少的知识，极少进城的我并没有预料到会因为这个被警察蜀黍拦下。好在还有个备用方案。
我有着奇怪的执念，来到一座城市，一定要去这座城市的博物馆看看。最后在我的强烈建议下，我们改道去了最近的浙江省博之江馆区。之江馆可能没有主馆那么有名气，可胜在节假日期间免预约参观，展出的藏品也并非等闲之辈。虽然记不太清当时的心情，但就拍下的照片数量来看，也是度过了一段不错的时光。
第三天，我发誓再不能像前两天那样莽撞了，既然是旅行，那么基本的规划的还是要有的。于是，我把这次旅程的终点定在了西湖。作为杭州的名片之一，西湖的风景向来声名远扬，三潭映月、断桥残雪、苏堤春晓……既然难得来一次杭州，总归要亲眼见识一番。
我们从住所乘坐地铁直达西湖景区，刚出地铁站时还没什么人影，直到隐约望见湖面，才注意到湖畔早已围满了乌泱泱的人群。我顿时无端联想起「烂怂大雁塔」来——或许对本地市民而言早已司空见惯，但外地游客眼中却依旧新鲜得不行的景点，大多都是这副模样。
今天的天气要比前两天好上许多，万里无云，气温也恰到好处。我们扎进人群里，顺着湖岸慢慢走着，一边欣赏沿途的风景，一边随手拍照。清晨的春风拂过湖面，带着些许水汽，湖水在阳光下泛起细碎的光斑，几对鸳鸯正悠闲地戏水；对岸的山峰层层叠叠、远近错落，被薄薄的春雾勾勒出轮廓。看到这样的景象，我们便停下来多按了几次快门。就这样走走停停，拍拍看看，不知不觉间过去了大半天。
我们绕着西湖走了一圈，基本上把能免费逛的景点都走完了。本想着离开前上雷峰塔眺望一下全景，可人实在太多，只是站在远处看了一眼，便作罢了。
俗话说「上有天堂，下有苏杭」。于是在国庆前夕，我去了趟苏州。
原本我是打算去上海市区逛逛的，但一时间又想不出上海究竟有什么非去不可的地方。朋友提议，不如干脆去隔壁的苏州看看。我盘算了一下行程：从住处坐地铁到上海西站大约五十分钟，再从上海西站搭动车到苏州站，只要半小时。算下来花费的时间和去一趟上海市区其实也差不了多少——既然如此，似乎也没有不去一次苏州的理由了。
可这算是场说走就走的旅行，我几乎没有作任何规划，毕竟本来就只是想逃离工位、出门喘口气而已。于是，在十一点抵达苏州站的那一刻，我毫不意外地陷入了「我是谁，我在哪，我要做什么」的窘境。可也不能一直在站台上干愣着，踟蹰片刻，便赶忙跟着人流往外走。我是个实打实的路痴，属于跟着导航坐公交都能坐反的那种，当务之急还是先离开火车站，钻进地铁里再说。
许是国庆调休的缘故，苏州站的地铁里竟没什么乘客。难得能这样不慌不忙地坐着地铁，我掏出手机，向场外观众求助。不少当地群友纷纷献计：苏博、拙政园、观前街、平江路、金地广场、金鸡湖……苏博的门票预约已经排到了国庆，没戏；拙政园倒是不限人次，可以进去转转；观前街和平江路二选一的话，群友们一致推荐后者，据说那是条古色古香的老街，兴许能见识到不一样的韵味；金地广场有不少二次元谷子，我对这种周边没什么兴趣，但倒也能去凑凑二次元的热闹；至于金鸡湖，最适合的便是傍晚时分去看一场初秋的日落。
但还没等我进一步规划，肚子开始表态了，定是赶车起得太早的缘故。这下不用纠结了，先从苏博出发，穿过平江路的古巷，去群友力荐的凤游记面馆来一碗地道的苏式面供奉一下五脏庙，再折回来逛拙政园。
苏博门口除了聚集着来自五湖四海的游客，还有不少兜售不知名小白花环的大爷大妈。我对这花很是好奇，本想凑到跟前看个仔细，愣是没有一个人冲我叫卖。我只好悻悻地继续朝平江路走去。
在经历走错方向来回折返、被路人当成本地人问路后，我终于在十二点前找到了平江路北路口。身为南方人，对教科书上的「江南水乡」多少还是有些刻板印象的：白墙黑瓦、临水而居、垂柳拂岸，这些元素拼凑出人们心目中的江南。可即便是保护得再到位的古街，也很难完全抹去现代生活留下的痕迹。平江路同样如此。但仅仅只是江南的一角，也足够游客打卡留念了。街上随处可见穿各色汉服、旗袍的姑娘倚靠在护栏上拍照，我也是直到这时才懂得群友提到的「古风妹妹」是什么意思。
边走边拍、花了半个小时穿过平江路后，我找到了凤游记面馆，点了一份群友推荐的「焖肉面」套餐，滋溜下肚。又稍微歇息了片刻，便折返回去逛拙政园。
稍微点评下这面。饭前小吃是芋头丸子和一小盏茶，偏甜；面分量很足，但焖肉略油。整体不赖，苏沪一代似乎喜爱甜食，我大概是吃不惯……
返程是不怕迷路了。找到最近的地铁站，再看准「拙政园苏博」方向，一站便到。苏博光是围墙设计就让人眼前一亮，虽是立体的屋檐，黑白纵深却好似平面画。可惜没有提前预约，没法进去游览一番。
拙政园在苏博的另一头，成人门票80元。我对园林设计几乎没有概念，也说不出什么门道，但多少还是能从这些空间的具体用途里一窥园主的用意：赏景。无论是四面厅堂、跨溪廊桥，还是假山、荷花池，都是为了引导人的视线，或将目光送向远处的风景，或让亭台建筑本身成为取景框，通过窗户或门框切割画面，只留下其中最耐看的一处。
From未来的me：你懂个屁的园林，明明是看不懂找个地方蹲着刷了会视频才后知后觉的！
在园里又迷了会儿路，大致逛完已经快四点了，接下来该去见识下二次元了。
花了半个小时乘4号线坐到南门，又用了几分钟走到金地广场。我围着广场外边绕了好几圈，一度怀疑自己是不是来错地方了，毕竟我连个通往二次元的大门都没找着。可迎面走来的几个玩 Cosplay 的年轻人，又明示着这里的确有二次元在活动。兴许跟着他们就能找到入口，我急忙尾随了上去。
果不其然。在找到商场正门后，没几步便看到了各式各样的二次元潮玩店、谷子商铺。商场并不是很热闹，但现在应该是放学时间，随便走走就能看到围在墙角打 UNO、玩累了写两道题的学生。真青春啊，想想自己小时候只能玩泥巴，现在的孩子已经能玩 Cosplay 消磨时间了。不过我对吧唧、立牌这类周边兴趣不大，粗略看了看便离去了。
金鸡湖可以乘地铁直达，出站后朝着苏州文化艺术中心的方向走即可。只是等我走出地表，太阳已临近落山。大概是赶不上看日落了。我爬上地铁头上的小坡，坐在石阶上，望着远方泛黄的天空发了会儿呆。
月光码头就在艺术中心边上，但我已经走了大半天，再绕着金鸡湖徒步一圈是万万不可能了，逛逛月光码头便是我今天的极限。可在码头里又迷了路，我只好在湖岸找了块地吹晚风。湖水拍打着岸边，夹杂着一旁车水马龙的声音，甚是喧嚣。可我却觉得，若不是第二天还要赶回去上班，我可以就这么一直坐着，直到这座城市慢慢安静下来。
等到约好的朋友赶来面基，向他抱怨了工作上的烦心事、吃好饭，跟着他往大裤衩底下的商店逛了逛，便回去了。
2025年，我去看了人生中的第一场交响音乐会，主题是我非常喜欢的动画《摇曳露营△》。早在看《四月是你的谎言》时，我就希望朝一日能去听一场主题音乐会，却始终没能如愿。如今有机会前往《摇曳露营△》十周年的首场海外交响音乐会，自然不想错过。
我第一时间联系了计划国庆来上海旅游的同学。我告诉他，这次音乐会，キミのね和亚咲花都会亲临舞台献声，立山秋航也会在现场亮相。亚咲花是《摇曳露营△》的老朋友了，キミのね虽然是新面孔，知名度也不及亚咲花，但就声线来看，百分百是辻诗音的马甲。同学虽然对亚咲花无感，但听闻有辻诗音，顿时起了兴趣。于是，他非常给力地帮我抢到票，还速刷了两季动画以便陪我一块看音乐会。可惜经验不足，我们并没有提前候在音乐厅门前，只是打算提前十分钟入场检票。结果便是，我们没有充足的时间，和聚集在门口的一众同好畅聊《摇曳露营△》，也没来得及多拍几张爱好者的痛车和露营道具，便匆匆进场了。
音乐会自然是非常地美妙。当各表演者依次落座，清脆的打火机声响起，伴随着木柴燃烧的爆裂声，一曲《ゆるキャン△のテーマ》为音乐会拉开了序幕。现场各声部发出的声音，确实和耳机里听到的音乐有着天壤之别，我几乎想跟着旋律一块吹起口哨来。但周围的人都正襟危坐，静静聆听。碍于音乐会这种特殊场合的严肃性，我也只能在心里手舞足蹈。甚至都不敢掏出手机拍照。
可随着气氛渐入佳境，情绪被不断推高，邻座的哥们已经按捺不住，开始左右摆手，前排角落的朋友也有备而来，跟随节奏挥舞起了绿色的荧光棒。更有后排的哥们在亚咲花登台的时候，大喊了声「お誕生日おめでとう！」，全场随之躁动起来。这等场合此举成何体统！可我实在忍不住，也跟着喊了一句。
原来今天还是亚咲花的生日，这我确实没有提前调查。
音乐会结束后，我们排队领取签名色纸。按主办方规定，是不允许同歌手合影拍照的，所以我以为只是领了色纸便结束了。可没想到，在领取色纸时，亚咲花不仅热情地向我们「ありがとう」，还在我因社恐领完便转身离去时喊住我，朝我挥手道别。没能向她致以同等的感谢，是我此次音乐会最大的遗憾。
第二天，我和同学逛了 B 站和海洋堂联合举办的 Wonder Festival 手办模型展。由于是 WF 的第二天也是最后一天，再加上入馆稍晚了些，我们放弃了做任务捡小垃圾，改为尽情地拍摄精美的塑料小人。
这些还只是场馆的冰山一角。我们从上午逛到临近闭馆，可能连企业馆的一半都没有走完。更要命的是，在最后的一小时里，我花了三十分钟去排了叔叔的残次手办专销的队，买了一个景品泡面压……于是，我们成功错过了个人展馆。
我们去个人馆的时候，大佬们的摊位已经收了个七七八八，剩下的也基本准备收摊了，打的灯都熄了个精光。个人馆虽然只有一个场馆，但胜在大佬们的 XP 千奇百怪，触手、多目怪，还有一些光是看着就让人掉 SAN 的奇特生物……即便我无法理解，但能在这里见识到这类手办，已经算是一件幸事了。
XP 太怪了，我甚至没敢拍（
今年已经是我在上海的第二个年头了，我仍在日复一日、机械式地重复劳作。这份几乎没有休假的工作，既没有充足的时间让我去见识繁华的国际化大都市，也没有足够的工资支撑我在一线城市消费。好在，经历过去年初来乍到时的种种不适，今年的我至少入门了上班的诀窍：少做、少问、多摸鱼。可偶尔还是太过自觉，招揽了不属于自己的活；也时常和无理取闹的老板拌嘴，给自己徒增烦恼。来年的话，希望自己能灵活变通，不该管的事要当作没看见，好让这个班上起来没那么苦闷。
我也利用起短暂的下班时间，去尽可能做一些与众不同的事。我买了把电吉他，尝试学习喜欢的曲子。我开始走出门去，享受这座城市为每一位二次元爱好者提供的便利。而这些，都离不开 Connorjam 的帮助。是他不厌其烦地将我从无趣的生活中打捞起来，拉着我奔赴一场场次元之约；也是他每天盯着我练琴，不然这把电吉他怕是早就在三天打鱼两天晒网的节奏里落满了灰，即便我现在也只是会弹小星星。
我在初冬的晨光中漫过武康路的街衢，也在巡游的卡车间写下如我们所书的寄语。
我在暮色里仰望过萨姆机甲的炽翼，也在特展的光影里触摸翁法罗斯的余温。
我知道，明年的日子大概率还是会同现在一样循环反复。那些没解决的烦恼、没涨起来的工资、没改掉的毛病，或许还会一次次找上门来。可没关系，我已经学会在这样的日子里，为自己留下一点出口。哪怕只是下班后练几遍不成调的曲子，哪怕只是在人群中确认某些熟悉的热爱依然存在，也足以让我把今天过完。
那么就这样吧，我们明天再见。
2025-12-25 19:53:00
最近购置了一台 1H1G、20G SSD 的虚拟服务器，为了便于使用，需要配置一下基础环境，例如新建用户、密钥登录、Docker 和 Zsh 等等。
年初参考过《Debian Server 初始化设置 SOP》的流程，也整理了一份《飞牛 fnOS 初始化配置记录》，但都不太适合直接套用到这台机子上。部分命令在 Debian 13 上也不再适用。于是，我决定按照自己的需求重新抄写一份，并用这篇笔记为今年的水文画上句号。
抄过来就是我自己的东西了！
本节命令全部使用 root 用户执行。
官方预装的是 Debian 12，系统相当干净，没有多余的东西，因而无需重装系统。既然是新开通的实例，没有任何业务负担，那么可以放心地进行大版本升级。我决定趁现在就把它更新到最新的 Debian13，满足我积攒已久的升级欲望。
首先，升级系统到最新状态：
apt update
apt upgrade -y
apt full-upgrade -y
apt autoremove -y
apt autoclean接着，将软件源切换到 Debian 13（trixie），使用以下命令一键修改 /etc/apt/sources.list：
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list /etc/apt/sources.list.d/*.{list,sources} 2>/dev/null然后再次升级系统：
apt update
apt upgrade -y
apt full-upgrade -y
apt autoclean
apt autoremove -y弹出的选框可以全部按默认选择，待更新完毕后，重启系统：
reboot重启后，验证系统版本：
lsb_release -a如果显示类似以下信息，说明已经升级成功：
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 13 (trixie)
Release: 13
Codename: trixie设置时区与 NTP：
timedatectl set-timezone Asia/Hong_Kong
timedatectl set-ntp true
timedatectl status输出类似：
System clock synchronized: yes
NTP service: active配置语言环境：
sed -i 's/^# *zh_CN.UTF-8 UTF-8/zh_CN.UTF-8 UTF-8/' /etc/locale.gen
sed -i 's/^# *en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/locale.gen
locale-gen输出类似：
Generating locales (this might take a while)...
en_US.UTF-8... done
zh_CN.UTF-8... done
en_US.UTF-8... done
Generation complete.安装一些基础工具，涵盖编译环境、系统管理、网络下载、终端增强以及文件处理等我可能用得到但又用不到的功能：
apt install -y build-essential sudo vim curl wget ufw autojump git tmux zsh tree zstd zip unzip lsof fastfetch rsync先设置一个新用户的环境变量，例如 mikusa，用于后续复制粘贴快速执行命令：
USERNAME=mikusa创建该用户，并将其添加到 sudo 用户组：
useradd -m $USERNAME
usermod -aG sudo $USERNAME为用户设置本地密码（可选，以防特殊情况需要，密码尽量复杂）：
passwd $USERNAME设置该用户执行 sudo 命令时免密：
echo "$USERNAME ALL=(ALL:ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/$USERNAME-nopasswd > /dev/null
chmod 440 /etc/sudoers.d/$USERNAME-nopasswd为该用户配置密钥登录，我有现成的公钥，所以这里直接设置一个公钥变量：
PUBKEY="ssh-ed25519 AAAABBBBBVVVVVVVVVVVVVVVVVVVV"创建用户密钥文件夹并授权：
mkdir -p /home/$USERNAME/.ssh
chmod 700 /home/$USERNAME/.ssh导入现有公钥：
echo "$PUBKEY" | sudo tee /home/$USERNAME/.ssh/authorized_keys > /dev/null修改权限：
chmod 600 /home/$USERNAME/.ssh/authorized_keys
chown -R $USERNAME:$USERNAME /home/$USERNAME/.ssh使用官方命令一键安装：
curl -fsSL https://get.docker.com | bash -s docker安装完毕后，使用以下命令验证 docker 和 docker compose：
docker info
docker compose version再将个人用户添加到 docker 用户组：
usermod -aG docker $USERNAME需用户退出当前终端、重新登录后，docker 组权限才会生效。
切换到 mikusa 用户：
su - mikusa才能继续执行下列个人用户相关的配置。
使用脚本一键安装 Oh My Zsh ：
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"安装后会询问是否切换 Shell 为 Zsh，按 y 同意。
安装刚需插件：
git clone https://github.com/zsh-users/zsh-autosuggestions.git ~/.oh-my-zsh/custom/plugins/zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ~/.oh-my-zsh/custom/plugins/zsh-syntax-highlighting修改主题为 ys：
sed -i 's/^ZSH_THEME=".*"/ZSH_THEME="ys"/' ~/.zshrc配置 Zsh，启用插件：
echo ". /usr/share/autojump/autojump.sh" >> ~/.zshrc
sed -i.bak 's/plugins=(\(.*\))/plugins=(\1 autojump zsh-autosuggestions zsh-syntax-highlighting z extract sudo cp aliases docker docker-compose)/' ~/.zshrc添加一些自用 docker 别名：
cat <<'EOF' >> ~/.zshrc
# Docker aliases
alias dcu="docker compose up -d --remove-orphans" ## 启动服务并移除多余容器
alias dcd="docker compose down" ## 停止并删除服务容器
alias dcp="docker compose pull" ## 拉取镜像
alias dps="docker ps" ## 查看运行中的容器
alias dlogs="docker logs --follow -n 15" ## 查看容器日志，跟随最新 15 条
alias dclean="docker image prune -a" ## 清理未使用镜像
alias acme.sh="docker exec acme.sh acme.sh" ## 在 acme.sh 容器中执行 acme.sh
alias nginx="docker exec nginx nginx" ## 在 nginx 容器中执行 nginx 命令
alias caddy-reload="docker exec -w /etc/caddy caddy sh -c 'caddy fmt --overwrite && caddy reload'" ## 格式化 Caddyfile 并重载 Caddy
alias caddy="docker exec caddy caddy" ## 在 Caddy 容器中执行 caddy 命令
EOF再重载 Zsh：
source ~/.zshrc可以安装一个 trash-cli 作回收站用：
sudo apt install -y trash-cli追加别名：
cat <<'EOF' >> ~/.zshrc
# trash-cli aliases
alias rm='trash-put' ## trash-put 将文件或目录移入回收站
alias rmclean='trash-empty' ## trash-empty 清空回收站
alias rmrest='trash-restore' ## trash-restore 还原回收站中的文件
alias rmlist='trash-list' ## trash-list 列出回收站中的文件
alias rmrm='trash-rm' ## trash-rm 删除回收站中的单个文件
EOF后续使用 rm 命令，便无须担心误操作删除文件了。
使用新用户通过密钥连接上实例，并确认一切正常后，再修改 SSH 配置，避免因误操作而失联。
先修改默认的 SSH 端口。设置一个端口变量，例如：
PORT=22033一键替换当前端口：
sudo sed -i "s/^#\?Port .*/Port $PORT/" /etc/ssh/sshd_config验证 /etc/ssh/sshd_config 配置是否有误：
sshd -t没有报错的话，重启 SSH：
systemctl reload sshd测试是否已成功绑定到新端口：
ss -tlnp | grep ssh有类似以下输出，即表示修改完毕：
root@Reze:~# ss -tlnp | grep ssh
LISTEN 0 128 0.0.0.0:22033 0.0.0.0:* users:(("sshd",pid=733,fd=6))
LISTEN 0 128 [::]:22033 [::]:* users:(("sshd",pid=733,fd=7))再考虑禁用 root 登录：
sudo sed -i 's/^#\?PermitRootLogin .*/PermitRootLogin no/' /etc/ssh/sshd_config也可以禁用密码登录：
sudo sed -i 's/^#\?PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config使用以下命令查看是否已成功修改：
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'若输出：
permitrootlogin no
passwordauthentication no即表示禁止 root 登录，也禁止密码登录生效。
随后重载 SSH：
systemctl reload sshd使用 reload 而非 restart，可避免因配置错误断开当前连接。
最后，在确认新端口和密钥登录都可用后，再断开当前连接。
2025-12-08 22:32:00
我喜欢收集插图。
小的时候，我会把卡通图画剪下来贴进本子里，做成小手账；再大些有了零花钱，我便攒着买来一本本畅销的画册；等到有了智能手机、接触到广阔的互联网世界，可收藏的东西一下子变得多了起来：从同人插图到概念设定，从商业插画到独立艺术家作品……我乐此不疲地保存这些图片，一张又一张，一个文件夹接着一个文件夹。
这大概是我坚持最久、也最投入的一个爱好。
可随着时间的推移，收集的作品越来越多，面对电脑中杂乱无章的图库，我才意识到一个问题：该如何为这些收藏进行分类？
相比影音或图书领域有成熟的管理程序和外部数据库可供整理，电子图片往往只是作者在插画网站上的一次更新，或社交平台上的一条动态，本身并没有过于明确的分类依据。我曾考虑使用标签的方式分类，但这么做大概需要一个形似 Yande.re 的图片程序记录标签，并在收集的时候为每张图片打上标签。新增图片尚可如此处理，存量图片就要麻烦得多——以我的技术能力还无法做到自动为每张图片打上标签。而网上搜索到的图片整理软件大多面向专业设计师，对于个人的插画收集而言，又有些大材小用。
况且，在使用 fnOS 相册、immich 这些带 AI 索引功能的相册程序之后，标签可能就没有存在的必要了。想要什么风格的图片，只需几个形容词简单描述，就可以快速检索到位。
因此，与其折腾复杂的分类系统，不如把精力放在图片本身的保存上。我决定只做最基本的「来源 + 作者」分类：
可是，在准备整理这些图片时，眼前的问题又让我犯了难。
由于没有电脑，最初的收集工作是在手机上完成的，自然没有、也不可能意识到未来会有分类的需求。所有图片都通过 Pixiv APP 保存在固定的文件夹里，再由相册的云服务功能同步到云端。这样做固然方便，更换手机也不怕图片丢失，但缺点同样明显：一旦保存时的命名格式发生变化，就很容易重复保存同一张图片。
例如，Pixiv 官方 APP 当前保存图片的命名格式是 illust_id_save_data.jpg，会生成诸如 illust_112251893_20251123_202020.jpg 这种带没有必要的 文件名；第三方 APP 则可以自行设置不同的命名格式，比如 illust 前缀和具体下载日期的又臭又长的非常不 Elegant 的112251893_p0.jpg 。当同一作品在不同时间、以不同文件名被保存时，就难以仅凭手机相册的时间轴判断是否重复收藏，当时的相册 APP 也缺乏扫描重复图片的功能。
▼ 不同时期的文件命名格式不同，我也是近些年才有所规范。
此外，早期的 Pixiv 还能下载到作者上传的未经去除 Exif 信息的原始图片，且图片格式可能是 jpg 、png 和 bmp 2，导致获取的同一作品甚至连文件体积也可能不一致。
所以，我决定先从「去重」这一步入手。针对完全一致的 MD5、相同的文件名，以及相近的文件大小，可以利用重复文件清理工具「Duplicate Cleaner」快速清理掉这部分特征明显的图片。而内容完全一致、只有文件格式或体积有区别的图片，可以在后续通过 immich 的去重功能筛选出来。
「移动」方面，由于几乎所有的 Pixiv 图片都包含一串作品 ID，处理起来相对方便。我的思路是利用 PID 拼接链接访问作品页面、解析作者的 UID 后，按 UID 建立作者文件夹移动图片。我把这份工作交给了 AI，编写了脚本批量移动。
▼ 其实最初我是按 UID(NAME) 的格式命名作者文件夹的，但总有作者爱改昵称，于是我又用 AI 糊了个脚本，把文件夹中昵称的部分统统删除了。
至于 PID 异常或是已被删除无法解析链接的作品，可以通过 SauceNao 溯源，再移动到对应文件夹。
最终，仅是 Pixiv 3就整理出了 12172 张（可能）4不重复的图片，这些图片来自 2750 位（可能）5不同的插画师。
至此，对存量图片的处理工作算是告一段落。接下来就可以把整理后的图片上传 NAS，并将其挂载到 immich 作为外部图库以便随时浏览和检索。
我的计划是，既然收图的重心正逐渐从手机转移到电脑，而电脑上又有各种现成的工具可以快速从 Pixiv 下载图片（例如：PixivBatchDownloader），那不妨就直接利用这些工具，按自己喜欢的规则生成文件夹和文件名。这样浏览插图时既可以顺手下载，又能通过工具保存下载记录，有效避免了重复下载。
接着，我只需把插图保存在 OneDrive 的同步目录里，就能自动同步到云端，再配置好群晖 DSM 的「CloudSync」套件，就能定时将插图从 OneDrive 拉取更新到 NAS。这样一来，我不仅可以随时在电脑上下载新的插图，还能通过 immich 集中统一管理，可谓一举多得。
唯一的问题是，CloudSync 偶尔会抽风。有时无法及时从云端拉取文件，有时又把我从 immich 中删除的图片同步回来……这些都还算能接受，直到后来出了点小意外。
2025 年初，闲来无事的我准备清理一下 DSM 中无用的数据，决定卸载一个用不到的第三方社群的 Python 套件，并在卸载时并勾选了「清理数据」。万万没想到，这个套件的数据路径竟指向了 NAS 的磁盘根目录，于是它在清理自身残留文件的同时，也顺便删掉了目录下其他的文件。
等我意识到不对劲紧急关机，满满 14T 硬盘的收藏已经被删得只剩下一半。
好在丢的都是些不算特别重要的影视剧和动画，有空再下回来就是。真正让我恼火的是不知何时还会出岔子的 DSM，尽管责任在我，是我自己安装非官方认证的第三方套件导致的。
我本就不太喜欢 DSM，既然事情已经发展到这一步，索性连同 NAS 系统一并更换，试试近期大火的 fnOS。
只是，此时的 fnOS 尚处在测试阶段，还未开发类似 CloudSync 的同步工具，无法直接从 Onedrive 同步文件，原本依赖 OneDrive 的备份方案就这样中道崩殂，插图收藏也因此停滞。我只得另寻其他既能兼顾下载、又能便于同步收藏的方法。
归根结底，我的需求无非就是先获取插图再保存到 NAS，仅此而已。既然终点是 NAS，为何不跳过这些弯弯绕绕，直接一步到位？在互联网上寻找了一番，我决定使用 Nazurin 实现这一思路。
Nazurin 是一个基于 Telegram 的图片收藏工具，支持从 各种网站 浏览和下载图片。在配置好 Telegram bot 和目标 存储源 后，只需给 TG 机器人发送图片源链接，便可直接将图片保存至目的地。
其实前面的内容都是为了引出 Nazurin 的废话，写着写着写跑题了……
在以往的存图流程中，遇到需要保存的图片后，我必须：
浏览 图片 ➡️ 下载 图片 ➡️ 上传 NAS
中间省略了可能需要执行的分类和去重工作。
而在使用 Nazurin、将存储目的地直接设置为 NAS 本地后、并配置好各图片源的存储规则后，这个流程就被简化成了：
浏览 图片 ➡️ 分享 源链接至 TG 机器人
只需两步，图片便直接被保存到 NAS 中了，可谓一劳永逸！
而在换用 Nazurin 后，我仍可以在 PC 端保持原有的浏览习惯，像平常一样寻找插图，遇到喜欢的图片一键保存。仅仅只是「更换」了一个「下载」按钮：
也可以在移动设备上，将图片的源链接分享给 TG 机器人：
这或许相比直接使用 APP 一键保存略微曲折了些，但至少我不用担心图片的分类问题，也不用再烦恼如何把它们备份到 NAS 了。
另外，通过订阅各图站的 RSS 服务，我还可以在繁忙的时候第一时间在 TG 内获取时下热门图片，再择一收入囊中。代价是插图收集也因此失去了些许个性。
虽然官方演示是搭建在 Fly.io 上，但我有 NAS，所以直接部署在本地就好了！
安装 Nazurin 非常简单，使用 docker compose 即可一键部署：
services:
nazurin:
image: yyoung01/nazurin:latest
container_name: nazurin
user: 1000:1001 # 实测需指定用户运行
volumes:
- ./data:/app/data
- /vol1/1000/photos/Nazurin:/Nazurin # 替换为你的存储路径
# ports:
# - 8080:8080
environment:
# ---------- 必填项 ----------
- TOKEN=123456 # 替换为你的 Telegram 机器人 Token
- ENV=development
# - WEBHOOK_URL=http://127.0.0.1:8080
# - HOST=0.0.0.0
# - PORT=8080
- STORAGE=Local,Telegram
- DATABASE=Local
- ADMIN_ID=123456 # 替换为你的 Telegram 用户 ID
- ALBUM_ID=-10012345 # 替换为你的 Telegram 频道 ID
- STORAGE_DIR=/Nazurin # 需与挂载的内部存储路径一致
# ---------- 可选项 ----------
- TZ=Asia/Shanghai
- IS_PUBLIC=false
- RETRIES=8
- MAX_PARALLEL_DOWNLOAD=6
- HTTP_PROXY=http://mihomo:7890 # 替换为你的代理地址
- HTTPS_PROXY=http://mihomo:7890 # 替换为你的代理地址
- CLEANUP_INTERVAL=7
- FEEDBACK_TYPE=reply
- BILIBILI_FILE_PATH=Bilibili/{user[mid]}
- PIXIV_TOKEN=123456 # 替换为你的 Pixiv Token
- PIXIV_TRANSLATION=zh-CN
- PIXIV_FILE_PATH=Pixiv/{user[id]}
- PIXIV_FILE_NAME={filename}
- TWITTER_AUTH_TOKEN=123456 # 替换为你的 Bearer Token
- TWITTER_FILE_PATH=Twitter/{user[id_str]}
restart: always这里与官方提供的 docker-compose.yml 不同的是，官方指定了一个 env_file 配置，里面包含了完整的环境变量，即便绝大多数都可以保持默认，但数量仍多得吓人。所以我稍微精简了下，仅保留了部分自定义的内容。
在这个配置的环境变量中，可选项自定义的功能如下：
HTTP_PROXY ，但其实 HTTPS_PROXY 也是必须的可下载 Pixiv、Twitter、Bilibili 图片至指定作者文件夹
Pixiv/{user[id]}，会在 Pixiv 文件夹内建立 作者 ID 文件夹；文件名格式设置为纯数字 IDTwitter 下载路径设置为 Twitter/{user[id_str]} ，会在 Twitter 文件夹内建立 作者的 用户id 文件夹，例如 1507705239507329034。你可以使用这个链接 https://x.com/intent/user?user_id={user_id} 一键跳转到对应用户，如：https://x.com/intent/user?user_id=1507705239507329034
@用户名 文件夹，例如 https://x.com/xinzoruo 里的 xinzoruo ，那么可以使用 {user[screen_name]} 来设置作者文件夹 6
Bilibili/{user[mid]} ，会在 Bilibili 文件夹内建立作者的 uid 文件夹可以具体参考下节的配置说明。
这里详细说明几处需要额外注意的配置。
user: 实测需指定用户运行，懒得找可以直接使用 1000:1001，否则登录 SSH 后使用 id 获取你自己的 id
$ id
uid=1000(mikusa) gid=1001(Users) groups=1001(Users),994(docker),1000(Administrators)-100xxxxxx
production ，即 Webhook 模式，并指定挂载端口，才能搭配官方的 Nazurin 浏览器扩展 一键分享。否则，使用 development 模式，让机器人轮询访问 TG 即可。关于 Webhook 模式，官方的说明是：
发送到 Telegram 服务器的 Webhook URL，机器人的服务器应能通过此 URL 访问，应以/结尾，例如https://xxx.fly.dev/。
也就是说，这个 URL 需要被公开，且必须能被 Telegram 服务器访问，才能正常使用
这也意味着如果 Nazurin 是运行在家里的 NAS 上，为了正常使用官方的 浏览器扩展，必须将 Nazurin 反代至公网
HTTPS_PROXY ，否则无法正常下载 Pixiv 图片FEEDBACK_TYPE：收藏图片成功后的反馈方式，可选值如下：
reply：回复原消息reaction: 在原消息上添加表情回应both：回复并添加表情回应
如果你没有太多图站需要收集，那么便无需使用完整的 .env 文件，只需在环境变量中填写基本的 TG 配置，外加一条 Pixiv Token，就足够启动了。
当然，如果你想要更精细些的分类、更多的图站支持，或者是其它配置，例如外部数据库、云端存储、自定义其他图站的保存路径，就需要自行详细阅读官方文档后，再额外添加了。
完整的环境变量配置如下，注释部分已使用 AI 进行翻译：
点击展开完整环境变量
# 这是一个 .env 配置文件示例
# 更多信息请参阅：https://nazurin.readthedocs.io/getting-started/configuration/
# 修改数值并取消相应行的注释后，将文件重命名为 .env
# ---------- 必填项 ----------
# Telegram Bot 的令牌（token）
# TOKEN =
# 运行环境
# production: Webhook 模式；development: 轮询（Polling）模式
ENV = production
# Webhook 地址，例如：https://xxx.fly.dev/，必须以 '/' 结尾
# 使用 Webhook 模式时必填
# WEBHOOK_URL =
# 监听的主机地址，如果使用反向代理请设为 127.0.0.1
# 使用 Webhook 模式时必填
# HOST = 0.0.0.0
# 监听端口，如果部署在 Heroku 或 fly.io 上请注释掉本行
# 使用 Webhook 模式时必填
# PORT =
# 存储类型，用逗号分隔
STORAGE = Local
# 数据库类型
DATABASE = Local
# Telegram 图库频道 ID，可选（官方文档写的是 GALLERY_ID，这是个过时的变量，这里已经更改）
# ALBUM_ID =
# 管理员用户 ID
# ADMIN_ID =
# ---------- 可选项 ----------
# 存储目录路径
# STORAGE_DIR = Pictures
# 是否将此 Bot 设置为公开
# IS_PUBLIC = false
# 如果 IS_PUBLIC 为 True，则以下配置项将被忽略
# 允许的用户 ID（可多个）
# ALLOW_ID =
# 允许的用户名（可多个）
# ALLOW_USERNAME =
# 允许的群组 ID（可多个）
# ALLOW_GROUP =
# 重试次数
# RETRIES = 5
# 请求超时时间
# TIMEOUT = 20
# 下载文件时写入的分块大小（字节）
# DOWNLOAD_CHUNK_SIZE = 4096
# 最大并行下载数量
# MAX_PARALLEL_DOWNLOAD = 5
# 最大并行上传数量
# MAX_PARALLEL_UPLOAD = 5
# 网络请求的代理 URL，默认为系统环境设置
# HTTP_PROXY = http://127.0.0.1:7890
# 在图像说明（caption）中忽略的内容
# CAPTION_IGNORE =
# 临时目录清理间隔（天）
# CLEANUP_INTERVAL = 7
# 日志等级，参考：https://docs.python.org/3/howto/logging.html#logging-levels
# LOG_LEVEL = INFO
# 收藏图片成功后的反馈方式
# FEEDBACK_TYPE = reply
# ----- Google 服务 -----
# Firebase & Google Drive 的 API 凭证
# GOOGLE_APPLICATION_CREDENTIALS =
# ---------- 网站相关 ----------
# ----- Artstation -----
# 文件目录
# ARTSTATION_FILE_PATH = Artstation
# 文件名
# ARTSTATION_FILE_NAME = {title} ({hash_id}) - {filename}
# ----- Bilibili -----
# 文件目录
# BILIBILI_FILE_PATH = Bilibili
# 文件名
# BILIBILI_FILE_NAME = {id_str}_{index} - {user[name]}({user[mid]})
# ----- Bluesky -----
# 文件目录
# BLUESKY_FILE_PATH = Bluesky
# 文件名
# BLUESKY_FILE_NAME = {rkey}_{index} - {user[display_name]}({user[handle]})
# ----- Danbooru -----
# 文件目录
# DANBOORU_FILE_PATH = Danbooru
# 文件名
# DANBOORU_FILE_NAME = {id} - {filename}
# ----- DeviantArt -----
# 文件目录
# DEVIANT_ART_FILE_PATH = DeviantArt
# 文件名
# DEVIANT_ART_FILE_NAME = {title} - {deviationId}
# 下载文件的命名
# DEVIANT_ART_DOWNLOAD_NAME = {title} - {deviationId} - {prettyName}
# ----- Gelbooru -----
# 文件目录
# GELBOORU_FILE_PATH = Gelbooru
# 文件名
# GELBOORU_FILE_NAME = {id}
# ----- Kemono -----
# 文件目录
# KEMONO_FILE_PATH = Kemono
# 文件名
# KEMONO_FILE_NAME = {pretty_name}
# ----- Lofter -----
# 文件目录
# LOFTER_FILE_PATH = Lofter
# 文件名
# LOFTER_FILE_NAME = {id}_{index} - {nickName}({blogName})
# ----- Moebooru -----
# 文件目录
# {site_name} -> Yandere，{site_url} -> 'yande.re'
# MOEBOORU_FILE_PATH = {site_name}
# 文件名
# MOEBOORU_FILE_NAME = {filename}
# ----- Pixiv -----
# Refresh Token
# PIXIV_TOKEN =
# 图片镜像，可选
# PIXIV_MIRROR = i.pximg.net
# 标签翻译，可选
# PIXIV_TRANSLATION =
# 收藏隐私（public/private），可选
# PIXIV_BOOKMARK_PRIVACY = public
# 文件目录
# PIXIV_FILE_PATH = Pixiv
# 文件名
# PIXIV_FILE_NAME = {filename} - {title} - {user[name]}({user[id]})
# ----- Twitter -----
# API 选择，可选
# TWITTER_API = web
# Web API 的 Auth Token，可选
# TWITTER_AUTH_TOKEN =
# 文件目录
# TWITTER_FILE_PATH = Twitter
# 文件名
# TWITTER_FILE_NAME = {id_str}_{index} - {user[name]}({user[id_str]})
# ----- Wallhaven -----
# API Key，可选
# WALLHAVEN_API_KEY =
# 文件目录
# WALLHAVEN_FILE_PATH = Wallhaven
# 文件名
# WALLHAVEN_FILE_NAME = {id}
# ----- Weibo -----
# 文件目录
# WEIBO_FILE_PATH = Weibo
# 文件名
# WEIBO_FILE_NAME = {mid}_{index} - {user[screen_name]}({user[id]})
# ----- Zerochan -----
# 文件目录
# ZEROCHAN_FILE_PATH = Zerochan
# 文件名
# ZEROCHAN_FILE_NAME = {id} - {name}
# ---------- 数据库 ----------
# ----- MongoDB -----
# MONGO_URI = mongodb://localhost:27017/nazurin
# ----- Cloudant -----
# CLOUDANT_USER =
# CLOUDANT_APIKEY =
# CLOUDANT_DB = nazurin
# ---------- 存储 ----------
# ----- Telegram -----
# 图库频道 ID
# ALBUM_ID =
# ----- MEGA -----
# MEGA_USER =
# MEGA_PASS =
# ----- Google Drive -----
# 文件夹 ID
# GD_FOLDER =
# ----- OneDrive -----
# 应用（客户端）ID
# OD_CLIENT =
# Refresh Token
# OD_RF_TOKEN =
# 客户端密钥
# OD_SECRET =
# ----- S3 -----
# 终端节点（Endpoint）
# S3_ENDPOINT = s3.amazonaws.com
# Access Key
# S3_ACCESS_KEY =
# Secret Key
# S3_SECRET_KEY =
# 是否使用 SSL
# S3_SECURE = True
# 区域
# S3_REGION =
# Bucket 名称
# S3_BUCKET = nazurin
到这里，这篇文章就算彻底结束了。本来只是想简单写写 Nazurin 的用法，结果在开头卡了很久……于是就写成这样了。 
总之，如果你同我一样有收集插图的爱好，且拥有一台 NAS，或是一台小服务器，希望能随时随地地保存那些美好的图片，那么 Nazurin 会是个很不错的小助手。
bmp 格式不确定是不是 Pixiv 自带的，只是我整理时发现有保存这个格式的图片。 ↩
id_str 最为稳妥，这串数字是固定不变且唯一的，但 screen_name 又更加便于搜索，只需与 https://x.com/ 拼接即可。你可以按需求选择设置。2025-12-05 22:33:00
对于今年七月新番的阵容与质量，我的心中充满感恩，只有两个字可以形容我的心情：至福！
上个季度我只看了4部动画。周二晚上追一集《末日后酒店》，周日一觉睡醒看《PA饭》和《mono》，其余的夜晚就……不记得在做什么了。确实是想不起来，应该不会是被路过的JK吸血鬼相中而带着满城市夜游。但七月就不一样了！这个七月无敌豪华的续作阵容，加上厨力爆棚的漫改、轻改新作，长草期？不存在的，从周一到周日，我一口气追了十二部（除了周二实在无从下手）！
首先是热门续作。潜水搞笑番《碧蓝之海》第二季回归，依然是那个熟悉的「酒精与大海」配方；王道热血番《胆大党》第二季继续高能，《彻夜之歌》第二季和《更衣人偶坠入爱河》第二季也如约而至；就连扳机社十年前的无节操作品《吊带袜天使》也出了新系列。
新作同样精彩纷呈。《琉璃的宝石》刷新了大家对这类偏科普作品的认知，京阿尼出品的《小城日常》延续了其一贯的高质量风格。甜到发齁的《薰香花朵凛然绽放》和百合后宫番《我怎么可能成为你的恋人，不行不行！(※不是不可能！？)》则极大程度地满足了不同口味的恋爱党需求，屑粉毛 suki！
不过在这些新作中，有两部漫改作品略有争议。虽然它们制作精良，称得上是业界顶尖水平，却在剧情上败絮其中。一部是《章鱼噼的原罪》，另一部是《光死去的夏天》。这次的新番吐槽，就先讲讲这两部。
「原罪」是源自基督教神学的宗教术语，指的是「人类自出生起便带有的罪性」。据《圣经》记载，上帝创造了亚当和夏娃，并将他们安置在伊甸园中。园中有一棵「分辨善恶树」，上帝命令他们不可吃其果实，而二人却在蛇的引诱下违背了命令，吃下了禁果。这被视为人类第一次悖逆上帝的行为。于是，二人受到惩罚：必须承受生老病死、劳作痛苦等诅咒。从此，「原罪」进入了人类世界。
在《章鱼噼》的设定中，「Happy 星球」便是伊甸园，「妈妈」则是上帝，「章鱼星人」是上帝创世后未尝禁果的亚当与夏娃，它们纯洁、透明，不带一丝罪意。显然，《章鱼噼》标题所指的「原罪」并不能同上述宗教定义的「原罪」画上等号。来自 Happy 星球的章鱼噼善良、乐于助人、不求回报，只为博得他人的笑容，他并不存在这种与生俱来的罪。
「分辨善恶树」上的果实象征着道德认知、自我意识与自由意志的觉醒，章鱼噼并不拥有这些能力，而这才是章鱼噼的原罪。章鱼噼「无罪」的前提，是必须身处 Happy 星球，只有这样，他才能不因无知而伤人。一旦章鱼噼来到一个与 Happy 星截然不同的社会时，他的行为本身就构成了他的原罪。
因此，他无法理解静香身上的淤青，将真理奈的暴力当作是朋友之间的争吵，面对落在脸上的拳头也不会下意识躲避，甚至是亲临死亡也不会感到恐惧。
他无意中将自己那套简洁纯粹的逻辑强加于这个复杂多变的世界，以为这些问题只需一个 Happy 道具就能轻松解决，而一切烦恼只需要双方最终是 Happy 的就已足够。章鱼噼的一次次尝试，非但没能解决双方的矛盾，还将自己推向了罪恶的深渊。他没有意识到他人痛苦的根源，也没有发现他的善意对别人来说是一种暴力。哪怕经历无数轮回，他仍未能真正理解事件的本质。他落下的眼泪，也不过是因未能完成妈妈赋予的使命，仅此而已。
可这能全怪章鱼噼吗？不能。因为他面对的是连人类自己都可能无法根治的难题——校园霸凌。动画中的霸凌更是出于剧情的需要，被安置在了一个将现实放大了的极端残酷荒诞的世界，一个家长、学校乃至社会都对此无动于衷的环境。如果说东直树和真理奈受到的是源自家庭的暴力而难以被发现还情有可原，但是对静香在课堂上遭受到的最直接的暴力都视而不见，这种没有任何外部力量干预的霸凌，如此不切实际的背景，在现实生活中几乎不可能存在。
也就是说，作者根本就没打算往一个能彻底解决三个家庭矛盾的方向叙事，自然也就无法指望一个不谙世事的外星章鱼能在处理这些事上起到多大的作用。
所以故事的最后，章鱼噼付出了自己的生命，最后使用了一次 Happy 道具，让时间回到照相的前一刻，创造出了一条继「真理奈线」和「静香线」外，章鱼噼不存在的世界线。这条世界线的真理奈和静香依旧没能摆脱双方既有的命运，却因章鱼噼曾在另外两条线出现过，不经意间影响到了这条线的二人，从而团结在一起互相对抗命运的不公……即便我确实心有不甘，也只能默默接受这个结果。
我编不下去了，越想越气。太烂了这个结局，不会写就不要写。
《光死去的夏天》初看有很重的 BL 元素，这劝退了很多路人观众。其实随着剧情的发展，两位主角之间的情感实际上更接近兄弟情，中后期则像是父子关系。但动画在二人情感的刻画上、尤其是非人的「光」对佳纪谜一般的感情的深度描写，在故事前期有大量篇幅都着墨于此，导致这部动画实际上看起来就是很……BL。
不过，BL 并不影响我观看，这充其量算是引人注目的噱头，真正吸引我的是 CygamesPictures 高规格的制作水准。光是极其华丽且诡异的片头曲画面就已经值得我驻步，更不用说全片精心构筑的演出与光影，在贴合故事氛围时带来的视觉冲击。这让我得以将更多注意力集中在动画对「光」的由来、神秘的「取脑大人」以及乡村灵异怪谈这一系列故事主线的铺陈。
可真正开始往主线的方向叙事，已经是第 7 话的事了。渐渐地，那些原本用于营造恐怖氛围的光影和镜头设计，还没来得及给我带来预期的惊悚感，就随着第一季的结束被我遗忘了。反倒是动画对小镇夏日的描绘更让我印象深刻——聒噪的蝉鸣、蔚蓝的天空和远处绿色的山峰……我一定是牛马牛出问题了才会怀念这个。这或许暴露了动画本身可能存在的问题：悬疑与情感两条主线太过割裂。
这种割裂感，很大程度源自动画与原作连载方式的差异。漫画自 2021 年 8 月连载至今不过 31 话，更新周期缓慢，「光」身上的悬念与过去被当作长期伏笔埋在叙事深处，在月更节奏下反而不显得突兀。但改成动画后，这条悬疑线被前置为阶段性矛盾，却没有迎来匹配的阶段性解法，在短短 12 集的体量中，它既未推动剧情，又压住了情感线的自然生长，于是观感上的断层就格外明显。如果是 24 集的半年番，节奏会更从容，情感与悬疑能在相对合理的节点上交替发力，高潮也能在合适的时机爆发。但当故事在 12 集刚展开便戛然而止，原本应逐步累积的张力来不及释放，体验自然大打折扣。
等到我看过漫画再回过头看动画，这一问题更为突出。因为即便抽离那些悬疑背景，主角二人的心理变化与关系推进依然成立——动画真正的核心始终在于探讨类似「沼泽人」的身份同一性问题：
若一个在外貌、记忆、行为上皆与你熟悉之人无异的存在出现在面前，那你所认定的那个人仍然成立吗？当认知依附于记忆，情感依附于回忆，而记忆与回忆都已被复制、再现、模拟，那自我究竟指向肉体、意识，还是他者眼中被构造的形象？
以至于「光」究竟是谁，似乎并没有那么重要。
好在官方已经宣布制作第二季，届时将两季连起来看，体验应该会有所改善。只是对于愿意追番的观众来说，这漫长的等待未免有些煎熬。
2025-10-18 08:00:00
一月看得有些杂了，我决定静下心来，快快乐乐地看些日常番。
今年四月对我来说算是近几年比较差的，因为在这个多达 66 部番剧的春季档里，我只看完了两部原创动画、一部漫改动画和一部泡面，总计4部新番。《末日后酒店》、《时光流逝，饭菜依旧美味》均属本赛季十分亮眼的黑马，《mono女孩》稍显逊色但也不容小觑，《莉可丽丝：友谊是时间的窃贼》则是专属于粉丝的福利番外，短小精悍。
若是把两部看了一半的半年番《魔女与使魔》、《Summer Pockets》，也算上的话，四月总共是看了6部新番。
你可能会有疑问，「那不是还有《Re：从零开始的异世界生活 第三季 反击篇》这部强势续作吗？」诚然如此，这个四月还有口碑好转的《小市民系列 第二季》、庵野秀明的老朋友鹤卷和哉整的新活《机动战士高达 GQuuuuuuX》以及赛马娘新作《赛马娘 芦毛灰姑娘》，都是不可忽视的存在。可惜我连前作都没看过/完，新/续作肯定无法一拍脑门就囫囵吞枣看下去的。因此，这些已经是我所能选择的极限了。
没片看也没其他办法，说不定七月就有一堆新番等着我呢？
丛生的树枝从写字楼顶层钻出，枝叶顺着破碎的玻璃幕墙垂挂而下，藤蔓悄无声息地蔓延开来，把街道织成了一座绿色的迷宫。曾经人头攒动的商业街，如今只剩下塌陷的人行道、倒伏的广告牌和被锈蚀封死的店铺大门。阳光洒在褪色的招牌上，不知何处传来几声清脆的鸟鸣，显得格外寂静。
不知名病毒肆虐全球，人类相继逃往外太空，地球文明在顷刻间停止了运转。然而，街口尽头的银河楼酒店仿佛与这一切无关。门前的地面干净如常，墙面光滑整洁，楼顶的钟塔正有条不紊地向前迈进着每一格，仿佛末日未曾来临。酒店沉重的金属门缓缓开启，礼宾机器人如往昔般迎接崭新的一天。只是下一秒，它的机体便猛地一震，随即轰然倒地。蒸汽从关节缝隙中喷出，白色的烟雾在空气中弥散。伴随着低回的爵士乐，《末日后酒店》的故事就此拉开了序幕。
初见「末日后酒店」这个片名，我以为会是个类似《少女终末旅行》那样「苦中作乐」的悲剧故事，或如《末日列车去哪里？》般满载充满脑洞的异想天开。当一群机器人只是为了等候人类回归，而苦苦维护着一栋没有客人的酒店长达数百年，这怎么看都不会是一件快乐的事。谁料，这部作品却走上了《太空丹迪》式的荒诞之路。
既然酒店的存在是为了服务顾客，老板也未曾指定顾客必须得是地球人，那么在这个没有人类存在的世界，为了遵守向老板许下的承诺，服务外星人自然也是理所当然。我们因此得以见到形形色色的外星生物，以及落户地球、陪伴孤独的八千代度过漫长年月的狸猫星人家族。在他们的帮助下，酒店渐渐恢复了往日的生机。不仅修缮了基础设施，开创了特色料理，还陆续增设了温泉、酿酒工坊，顾客越来越多。在星际间打出名声后，甚至建立起面向全地球的防御系统——这些都在不经意间同酒店的运营宗旨相契合。
很难说《末日后酒店》是否正是从这「十律」出发，才延展出如此多姿的故事线的。
而作为一台依据程序设定运行的机器人，八千代理应按部就班地执行命令，履行代经理的代理的义务，向每位顾客致以最诚挚的笑容。但当她因不可抗力向狸猫星人一家施以正义的铁拳，触发了老板留在她体内的第一个彩蛋之后，她的轨迹便开始偏离原定的路线。从喝酒体验「大人的感觉」而获得性感身材、到被不可名状的心情影响得热水盈口；从意外迷失在外太空，到重返地球发现自己派不上用场，迎来青春期和叛逆期……酒店在成长，八千代亦在进化，她逐渐获得了那些原本只属于人类的「七情六欲」。
于是，当被迫休假的八千代第一次以一位普通的旅客的身份漫步在这座无人的城市，将目光从酒店从转移到这个荒芜的世界，时间的痕迹开始显现。散发着热气的温泉澡堂、金黄色的麦田、高耸的火箭发射场、郁郁葱葱的沙漠绿洲、爬满藤蔓的残垣断壁……看着眼前的这一切，她发出来自内心深处的感慨：「体验到了活着的感觉」。
这一刻，八千代俨然成了这个星球上全新的「人类」。
只可惜，偏向单元剧的结构让人几乎忘记《末日后酒店》终有落幕的一天。可它还是如钟塔那样准时，在第 12 集画下句点——伴随着人类的归来与离去。好在经历了这一切风风雨雨，八千代早已不再是那台只会机械微笑的机器人。她学会了思考和犹豫，理解了愤怒与感动，也懂得了「等待」并不只是程序设定的循环，而是一种源于心底的期盼。或许人类终究不会再回来，但她依然会在这栋酒店中等待着下一位旅客的到来。
P.A.WORKS 这些年一直在制作一些以少女为主的原创动画，但都收效甚微。例如 2017 年的《樱花任务》、2021年的《白沙的水族馆》，评价都较为一般。可能是因为把握不住半年番的时间跨度（这俩我都没看过，这段话是我瞎说的）。去年的《亦叶亦花》在 Bangumi 上只有凄惨的 4.95分，不过同期的《深夜重拳》还算说得过去，拿下了 7.34 分，可题材特殊，受众面太窄，只能沦为冷门佳作。本季的《PA 饭》1不仅讨论热度高，在日常氛围的营造上更是力压隔壁《mono 女孩》一筹，评分高达惊人的 7.7 分，仅次于《末日后酒店》。
这个成绩倒并不让人惊讶。PA 本来就是日常系动画的好手，只是最近做得烂了些，并不代表人家做不出来好看的动画。《PA 饭》和《mono 女孩》比，也就是制作精度差了点，人物崩坏现象频发了些。在高完成度的故事面前，这些都是瑕不掩瑜的小问题。毕竟《PA 饭》对「吃饭」与「生活」的结合与协调处理得恰到好处，故事节奏和剧情推动也十分舒适，加之各色的角色形象以及丰富的日常互动，构建出的一系列平淡却充满惊喜的放学后生活。这些都是大家有目共睹的。
以上图片来自 维基萌 。各位若有兴趣，不妨前往大佬博客阅览关于本作的圣地巡礼：《圣地巡礼之高尾与西八王子》、《吃动画中的巨无霸汉堡》、《联动女仆咖啡》。
更重要的是，《PA 饭》并非将重心全部都放在做饭、吃饭或是日常唠嗑上，而是借由「饭菜」这一载体，将五位角色紧密地联系在一起。例如第二集，面对空有名头的「饮食文化研究部」感到心灰意冷的真子，在和大活一块打扫活动室、指导员突袭检查活动状况后，萌生出想要做饭的念头，在同伴们的协作下完成一餐，继而收获以往独自一人所没有的喜悦；第三集相约爬山，与相识不久的美虹相遇聊天变得熟络，与大家一起登上梦寐以求的山顶，饱餐后欣赏与所不同的风景；第四集星奈奈的加入虽然充满尴尬的空气，但只一顿饭后，真子与她渐渐成为了无话不谈的好伙伴……
就这样，《PA 饭》每一集都在上演着值得回忆的美妙场景。正如同标题写的那样，重要的从来都不是饭菜，而是大家互相陪伴下缓缓流逝的时光。
《mono 女孩》是《摇曳露营》作者 あfろ 的另一力作，与《摇曳露营》属同一世界观。
只是，在因《摇曳露营》第三季大换血导致原本的空气感消失得不能说是一干二净也得是所剩无几的这个大前提下，接过「神之动画」接力棒的重担就落在了师出同门的《mono》身上。可谁知一季播毕，《摇曳露营》一转身，背后压根没人！再定睛一看，原来《mono》气喘吁吁地跑在另一条赛道。诶不是，你怎么跑得比《PA 饭》还慢？
说笑归说笑，但《mono》确实是远不及《摇曳露营》，甚至还有些落后《PA 饭》的。虽然动画在制作规格上诚意满满，但是对于「日常系动画」十分重要的氛围把控与立意表达上，制作组还是略显青涩。以至于观众看不明白《mono》想要讲述的究竟是一个怎样的故事，是美少女JK聚在一起玩摄影，还是春乃老师 2 和漫画家同伴们借取材之名公费旅游，还是大家闲暇时一起满地图闲逛打卡，还是三者皆有之的日常大杂烩。
摄影也好旅游也罢，亦或是网红景点打卡，我对《mono》的这一套连招并不反感。身经百战的我已经可以主动从夹角和缝隙中摄取美少女养分，再配合少女们纯真的笑容抚慰我疲惫的心灵。我无法忍受的是故事后半段频频出现的乡村灵异怪谈，即便它确实有趣。这段故事和先前轻松的日常相比，主角直接从三小只变成了漫画家社畜不说，原本溢出屏幕的青春还变得只剩下工作饭后的杂谈，有着非常明显的割裂感，实在是让人难以接受。
《mono》最终呈现的效果更像是 あfろ 老师在画《摇曳露营》时四处取材而积攒的素材库，并不只有摄影，而是镜头下包揽世间的万物，这可能才是作品真正的立意。如果大家更倾向《mono》会和《摇曳露营》一样，单纯地借「摄影」为由铺展开来一段段充满趣味与烟火气息的故事，那为何不直接再看一遍《摇曳露营》呢？
石蒜今年推出的三分钟的日常番外篇泡面——完全不够看啊！求求你再让我看一集吧，我什么都愿意做的！
要我说第二季干脆别惦记你那烂怂电波塔了，多写点美少女贴贴千束和泷奈的打情骂俏日常，然后在欢声笑语中再次迎来《花之塔》的吉他声响起。你开心，我开心，大家都开心，多么美妙的一件事！
OK，以上就是今年份的4月新番吐槽。虽然只有三部，还磕磕绊绊憋到了10月才写完，但写出来了总归是好的！这三部动画都是本季新番中的精品，如果你有时间亦有兴趣，不妨将这几部动画全部看完，说不定会收获和我完全不一样的体验。
还请期待下次的新番吐槽~
