Linux 设备上想顺畅地用阿里云盘这事儿我前前后后折腾了差不多三年。从最早的第三方客户端到自己搭 WebDAV 中间层再到用 rclone 把网盘直接挂成一个本地目录中间踩的坑够写满一个笔记本。你要是刚在虚拟机里装完 Linux、或者手上有台常年开机的服务器和 NAS想在命令行里直接摸到云盘里的文件那这套思路基本能覆盖你九成的需求。我不打算讲那种点两下就完事的假教程——Windows 和手机上当然简单但在 Linux 上它天然就是一道需要自己搭桥的题。下面我把方案选型、搭建过程、参数含义、常见故障一次性摊开讲清楚你把命令抄下来改改路径就能跑。1. 需求解构Linux 上缺的到底是什么1.1 三类典型场景诉求天差地别先说清楚一件事管你叫用阿里云盘其实落在 Linux 上至少分三种完全不同的诉求混在一起谈就会越谈越乱。第一种是桌面交互型。你在 Ubuntu、Deepin 或者国产 Linux 桌面上想有个图标能点开能拖文件进去能看着进度条。这类用户需要的其实是一个图形客户端最好能和文件管理器集成右键菜单里就有上传到云盘。第二种是目录挂载型。你希望云盘上的内容像本机的一块磁盘那样出现在/mnt/cloud下面ls、cp、cat、grep这些命令直接能用编辑器、播放器、下载工具也不需要知道文件其实在远端。NAS、家庭服务器、媒体中心基本都是这个诉求。第三种是脚本批处理型。你根本不需要看到文件只要能在定时任务里跑一句命令把本地某个目录递归同步上去或者把云端的备份拉下来。备份、日志归档、跨机同步都属于这一类。这三类的技术路线不一样选错了就会觉得怎么这么难用。很多人抱怨 Linux 上用网盘反人类其实是用桌面客户端的期待去要求一个命令行工具。1.2 官方客户端的空白位置阿里云盘官方客户端的覆盖范围一直是 Windows、macOS、iOS、Android 这几个主流平台Linux 原生版这么多年始终没有正式落地。移动端迭代到 5.x 之后功能越来越重桌面端也在更新但 Linux 这条线一直是社区自己在补。这不是阿里云盘一家的问题。绝大多数国内网盘在 Linux 桌面上都是空白原因也不难理解Linux 桌面用户基数小做一套要同时兼容 deb、rpm、AppImage还要处理各个发行版的依赖差异投入产出比确实不好看。但需求是真实存在的。国内这几年国产 Linux 发行版铺得很快办公、教育、开发场景里的装机量明显上涨再加上虚拟机装 Linux 学习、嵌入式设备跑 Linux 的群体大家都绕不开文件怎么和云盘打通这个问题。官方不给社区就得自己想办法于是就有了后面这几条路线。2. 三条技术路线先选对再动手2.1 路线A浏览器网页版最省事也最受限打开浏览器登录网页版这是零成本方案。上传下载、在线预览、分享管理都能做功能上其实覆盖了日常使用的大部分操作。它的硬伤也很明确所有操作都得人肉点。你没法在脚本里调用它没法让它在半夜自动把备份传上去大文件上传时浏览器标签页一关就可能中断。另外网页版对大文件的分片上传和断点续传支持取决于浏览器本身的稳定性长时间挂着不太可靠。我一般把网页版定位成应急和查看工具而不是生产环境的主力。真要批量处理文件别指望它。2.2 路线B挂载成本地目录Linux 用户的最优解核心思想是在中间跑一个程序把云盘的接口翻译成 Linux 能识别的文件系统接口然后通过 FUSE用户态文件系统挂到某个目录上。挂上之后/mnt/cloud看起来就是一块普通磁盘。这条路线里最常用的组合是一个提供 WebDAV 服务的中间层 rclone 做挂载。WebDAV 是个老协议基于 HTTP几乎所有操作系统和工具都认识它。中间层的作用是把阿里云盘的私有接口包装成标准的 WebDAV 接口然后 rclone 用 WebDAV 后端连上去再通过 FUSE 暴露成本地目录。为什么这么绕一圈因为 rclone 直连网盘官方接口的后端支持历史上经历过反复调整接口一变就得等社区跟进。而 WebDAV 是标准协议只要中间层稳定上层就稳。这一层解耦带来的稳定性是我最终选它的核心原因。好处很实在文件管理器能用命令行能用任何走 POSIX 接口的程序都能用。坏处是 FUSE 的转发有性能损耗随机读写的场景会明显比本地磁盘慢。2.3 路线C命令行工具直传快但不成体系第三条路是不挂载直接用命令行工具做上传下载。rclone 本身就带copy、sync、ls、cat这些子命令配合 WebDAV 后端能完成几乎所有批处理需求。这类方案的优势是没有常驻进程、没有 FUSE 开销、传输速度更接近带宽上限。适合备份、归档、定期同步这种跑一次就走的任务。缺点是它不提供目录这个概念。你不能在一个视频播放器里打开云端的电影也不能用编辑器直接保存到云端。每次操作都是一次独立的命令调用。我的实际做法是B 和 C 混用日常浏览和临时取文件走挂载目录定时备份和大批量传输走 rclone 的 copy/sync 命令。两套东西用的是同一份配置文件互不干扰。2.4 三条路线横向对照对比项路线A 网页版路线B 挂载目录路线C 命令行直传上手难度极低中等中等自动化能力无强强是否能被其他程序访问否是否大文件传输稳定性一般较好最好随机读写性能不适用较差不适用常驻资源占用无中等无适合场景应急查看日常使用、媒体库备份、批量同步看清这张表选型就不会纠结了。如果你只是偶尔传个文件别折腾挂载如果你要把它当工作目录用那就老老实实走路线 B。3. 从零开始把云盘挂进文件系统3.1 准备工作依赖、用户和目录规划先装依赖。不同发行版包名略有差异Debian 系大概是这样sudo apt update sudo apt install -y rclone fuse3 ca-certificatesFedora 系用dnf install rclone fuse3Arch 系pacman -S rclone fuse3。fuse3 是提供 FUSE 支持的rclone 挂载时依赖它。接下来有个容易被忽略但很关键的决策用哪个用户跑挂载进程。如果你用 root 跑挂载出来的目录默认只有 root 能访问普通用户进去就是权限不够。如果你用普通用户跑那这个用户至少需要对挂载点目录有读写权限。我踩过的最蠢的一个坑就是用 root 挂载然后用普通用户去访问ls出来一片空白还以为是挂载失败了。注意不建议长期用 root 跑 rclone mount。一旦配置里出了路径拼写错误root 权限下的删除操作是不可逆的。我的建议是专门建一个普通用户比如叫clouduser让它负责挂载再用--allow-other参数放开其他用户的访问sudo useradd -r -m -d /home/clouduser -s /usr/sbin/nologin clouduser sudo mkdir -p /mnt/cloud sudo chown clouduser:clouduser /mnt/cloud如果确实需要让其他用户访问挂载点还得在/etc/fuse.conf里打开一行sudo sed -i s/^#user_allow_other/user_allow_other/ /etc/fuse.conf这一行不开--allow-other会直接报错退出日志里写一句option allow_other only allowed if user_allow_other is set第一次看会一脸懵。3.2 搭好 WebDAV 中间层中间层的选择上社区里有几个开源项目在做这件事功能大同小异都是在本地起一个 HTTP 服务提供 WebDAV 接口和管理界面。具体用哪个我建议你看项目当前的活跃度和文档完整度再决定因为网盘接口本身会调整维护跟不上的项目容易失效。部署方式通常是 Docker最省心docker run -d \ --name cloud-gateway \ --restartunless-stopped \ -p 127.0.0.1:5244:5244 \ -v /srv/cloud-gateway/data:/opt/data \ 中间层镜像名这里有几个细节值得说端口映射写成127.0.0.1:5244:5244而不是5244:5244。绑到本地回环地址外部网络根本连不进来安全性直接拉满。除非你的 NAS 和客户端不在同一台机器上才需要绑定内网地址。数据目录挂到宿主机上配置和登录凭证在容器重建后不会丢。首次启动后进管理界面添加存储选择阿里云盘对应的驱动类型按提示完成授权一般是扫码或者填刷新令牌。授权成功后在管理界面的存储页面能看到这个挂载点通常会给你一个 WebDAV 地址形如http://127.0.0.1:5244/dav以及一组独立的 WebDAV 账号密码。这组账号密码和网盘账号是两回事别混用。提示WebDAV 的访问凭证建议单独设置不要和管理界面用同一套。管理界面暴露在网络里风险更高两者分开能把损失面控制住。3.3 rclone 配置第一次连接要验证什么有了 WebDAV 地址和凭证配置 rclone 就是标准流程rclone config进去之后选n新建填个名字比如cloud然后在后端列表里选webdav。接着依次填URLhttp://127.0.0.1:5244/dav服务商类型vendor选other用户名和密码填中间层给的那组 WebDAV 凭证密码这里有个细节rclone 会问你是否手动输入密码选是的话直接输明文选否则会在终端里做一次混淆obscure存到配置文件里的是一串加密后的字符串。我一般选手动输入然后用rclone obscure命令单独处理rclone obscure 你的密码把输出结果填进配置文件这样配置文件里就不会有明文密码。虽然这个混淆不是强加密但至少能防住别人随手cat一下配置文件就看到明文。配置完立刻验证rclone lsd cloud:这条命令列出根目录下的文件夹。如果能正常输出说明链路通了。如果报 401检查用户名密码如果连接被拒绝检查中间层是不是活着如果超时检查端口和防火墙。验证通过后再看看空间占用rclone about cloud:这条命令能返回总容量、已用容量、剩余容量。如果返回的是空值说明中间层没有实现这个接口属于正常现象不影响挂载。3.4 挂载参数怎么定一份带注释的配置这是整套方案里最关键的一步。参数调对了日常使用顺滑调错了会莫名其妙卡顿、丢文件、目录刷不出来。先手动跑一次确认没问题rclone mount cloud: /mnt/cloud \ --vfs-cache-mode full \ --vfs-cache-max-size 20G \ --vfs-cache-max-age 24h \ --dir-cache-time 12h \ --poll-interval 0 \ --buffer-size 32M \ --vfs-read-chunk-size 16M \ --vfs-read-chunk-size-limit 256M \ --allow-other \ --umask 022 \ --log-level INFO \ --log-file /var/log/rclone-mount.log \ --daemon逐个说清楚这些参数在干什么--vfs-cache-mode full是最重要的一个。它告诉 rclone 把所有读写都先经过本地磁盘缓存。默认的off模式下程序只能顺序读文件很多编辑器、压缩工具、视频播放器会直接报错因为它们需要先写后读或者随机访问。开成 full 之后兼容性最好代价是需要磁盘空间放缓存。--vfs-cache-max-size 20G限制缓存上限超了就按时间淘汰旧的。这个值要按你本机磁盘剩余空间来定别设得太激进把系统盘撑爆。--vfs-cache-max-age 24h是缓存文件的保留时间。设太短会导致频繁回源设太长会占空间。24 小时对大多数场景比较均衡。--dir-cache-time 12h控制目录列表的缓存时长。网盘这类远端存储列目录是最慢的操作之一。缓存久一点ls会快很多。但如果你在多台设备同时操作同一个目录缓存太久会看到过期的文件列表。--poll-interval 0关掉主动轮询变更。WebDAV 后端多数不支持服务端变更通知轮询会白白消耗请求配额直接关掉更省事。--vfs-read-chunk-size和--vfs-read-chunk-size-limit这一对是给大文件读取用的。起始 16M连续读的时候逐步放大到 256M这样既不会在小文件上浪费请求也能让大文件的吞吐跑起来。--buffer-size 32M是每个打开文件的内存缓冲区。文件并发数高的时候内存占用是 buffer 乘以并发数所以别一味往大调。--umask 022决定挂载出来的文件权限022 意味着同组和其他用户可读不可写。如果你需要多人协作写入改成002或者000但要清楚自己在放开什么。手动跑通之后用df -h看一眼挂载点有没有出现再ls /mnt/cloud确认能看到文件然后fusermount3 -u /mnt/cloud卸载准备做服务化。3.5 systemd 服务让它开机自己爬起来手动挂载最大的问题是重启就没了。写个 systemd unit 一劳永逸[Unit] DescriptionRclone mount for cloud disk Afternetwork-online.target Wantsnetwork-online.target [Service] Typenotify Userclouduser Groupclouduser ExecStart/usr/bin/rclone mount cloud: /mnt/cloud \ --config/home/clouduser/.config/rclone/rclone.conf \ --vfs-cache-mode full \ --vfs-cache-max-size 20G \ --vfs-cache-max-age 24h \ --dir-cache-time 12h \ --poll-interval 0 \ --buffer-size 32M \ --allow-other \ --umask 022 \ --log-level INFO \ --log-file /var/log/rclone-mount.log ExecStop/bin/fusermount3 -u /mnt/cloud Restarton-failure RestartSec10 [Install] WantedBymulti-user.target存成/etc/systemd/system/rclone-mount.service然后sudo systemctl daemon-reload sudo systemctl enable --now rclone-mount sudo systemctl status rclone-mount几个坑点提醒Afternetwork-online.target很必要。如果网络还没起来就挂载中间层连不上服务会启动失败然后不停重启。不过在本地跑中间层的情况下还要额外依赖 Docker 服务的启动顺序可以在After里加上docker.service。Typenotify让 systemd 等 rclone 真正挂载完成再认为服务启动成功。有些老版本 rclone 对 notify 支持不完整如果启动一直卡住改成Typesimple就行。ExecStop里的卸载命令普通用户执行fusermount3 -u需要对应权限。如果报错换成/bin/fusermount3 -uz加 z 表示强制懒卸载或者干脆让 systemd 自己处理。日志文件/var/log/rclone-mount.log的权限要提前处理好否则 clouduser 写不进去服务会启动失败但报错信息藏在 journal 里容易找半天。4. 落到具体场景三种高频用法4.1 服务器自动备份用 copy 而不是 sync备份场景我强烈建议用rclone copy而不是rclone sync。原因很直接sync会让目标目录和源目录完全一致源目录里删掉的文件目标端也会跟着删。这个行为在本地误删想从云端恢复的场景里是灾难性的。copy只做单向增量复制目标端多出来的文件不会被清理安全得多。写个备份脚本#!/usr/bin/env bash set -euo pipefail SRC/srv/data DSTcloud:/backup/$(hostname) LOG/var/log/cloud-backup.log echo [$(date %F %T)] backup start $LOG rclone copy $SRC $DST \ --transfers 4 \ --checkers 8 \ --retries 3 \ --low-level-retries 10 \ --log-file $LOG \ --log-level INFO echo [$(date %F %T)] backup done $LOG--transfers 4控制并发上传数。WebDAV 中间层的并发承受能力有限开太高反而容易触发限流或者连接被拒。4 到 8 是比较稳的区间具体看你中间层的性能。--checkers 8是用于比对的并发数。比对阶段只读元数据开销比传输小可以适当开高一点加快扫描。--retries和--low-level-retries处理网络抖动。网盘这类走公网的服务偶发的超时和连接重置很常见多给几次重试能显著降低任务失败率。配到 crontab 里每天凌晨跑一次0 3 * * * /usr/local/bin/cloud-backup.sh提示备份脚本一定要写日志。我第一次做自动备份时没记日志连续两周任务静默失败直到需要恢复文件才发现云端一个字节都没有。4.2 媒体库和大文件预览挂载目录直接喂给播放器或者图库程序是完全可行的但有几个调优点。首先是缓存策略。播放视频时--vfs-read-chunk-size从 16M 起步逐步放大到 256M配合--buffer-size能让首次缓冲更快。如果你的网盘服务在有线网络下带宽充足可以把这个起始值调到 32M减少初始的请求次数。其次是目录列表缓存。媒体库动辄几万个文件每次扫描都要列目录的话会把中间层压垮。--dir-cache-time设到 12 小时以上第一次扫描慢一点之后都快。第三个容易被忽略的点不要让媒体库程序去做全库写入操作。有些图库软件会在扫描时自动生成缩略图并写回原目录这在挂载目录上是灾难——每个缩略图都要走一次网络上传。要么关掉写回原目录的选项要么把缓存目录指到本地磁盘。4.3 多机同步和冲突处理两台以上设备同时挂载同一个网盘目录会遇到经典的同步冲突问题。挂载目录本质上是即时读写远端没有本地副本的概念。所以两台机器同时改同一个文件时后写的会覆盖先写的而且不会有任何提示。这个行为本身没错但你需要知道它存在。我的处理方式是把工作目录按机器划分cloud:/workspace/host-a/ cloud:/workspace/host-b/ cloud:/shared/每台机器只写自己那一份共享区只读不写。需要共享修改的文档走下载到本地、改完再上传的流程避免直接编辑。如果确实需要多人协作那就得靠文件本身带版本控制能力比如用 Git 仓库放在本地只把裸仓库同步上去或者靠中间层提供的回收站和版本历史功能来回滚。别指望挂载层帮你解决冲突。5. 常见问题与排查实录5.1 文件名乱码八成是编码问题这个坑我在从 Windows 迁移数据时踩得最狠。现象是挂载目录里文件名显示成一堆问号或者奇怪的符号ls出来一团糟。根本原因是文件名编码不一致。Windows 上的中文文件名历史遗留了大量 GBK 编码Linux 默认按 UTF-8 解析两边对不上就乱码了。排查步骤locale确认当前环境的字符集设置。如果是POSIX或者缺了UTF-8后缀先修正export LANGen_US.UTF-8 export LC_ALLen_US.UTF-8如果环境本身没问题那就是文件名本身就是 GBK 编码的。这时候可以用convmv批量转换convmv -f gbk -t utf-8 -r --notest /mnt/cloud/some-dir--notest表示真正执行不加这个参数只预览不修改。先不加参数跑一遍看看要改哪些确认无误再加。注意convmv会重命名文件在挂载目录上执行意味着执行一次真实的远端重命名操作。先在本地小目录上试确认无误再上生产数据。还有一种乱码出现在解压文件的时候。zip 格式在中文字符名上有历史包袱有些工具会按 GBK 解析。Linux 下用unzip时可以指定编码或者换用7z7z x archive.zip -mcp936-mcp936指定代码页为 GBK。这个参数不一定在所有版本里都生效如果不行就先用unzip -l看列表确认情况。5.2 挂载点突然消失目录变空这个现象很吓人ls /mnt/cloud返回空但其实云端文件一个没少。多数情况下是 FUSE 进程挂了或者中间层断了。排查顺序systemctl status rclone-mount mount | grep /mnt/cloud tail -n 50 /var/log/rclone-mount.log先看服务状态再看挂载表里还有没有这条记录。如果服务在跑但挂载没了日志里通常会有关键线索。常见原因有三个。一是中间层容器重启了rclone 的连接池失效二是网络中断时间长超过重试上限三是--vfs-cache-max-size把磁盘写满了缓存写不下去导致进程异常。第三点特别隐蔽。FUSE 挂载在磁盘满的时候表现很奇怪不会明确报磁盘已满而是各种操作超时。养成习惯把缓存目录放在空间充裕的分区上或者单独挂一块盘--cache-dir /srv/cache/rclone5.3 权限报错与 allow-other 那些事权限问题的表现是ls能看到文件但cat或者写入时报 Permission denied。三个方向排查。第一挂载进程和访问进程的用户是否一致。用ps -o user -p $(pgrep -f rclone mount)看一眼挂载是谁在跑。第二--allow-other是否生效/etc/fuse.conf里的user_allow_other有没有打开。第三--umask设成了多少。022 的话其他用户只有读权限没有写权限。要写入就得调小。还有一个更容易被忽略的点中间层那边对 WebDAV 账号的权限控制。有些中间层会区分只读和读写两种权限模式如果配置的时候选了只读本地怎么调都没用。5.4 传输中断、限速与配额大文件传到一半失败先看日志里的错误码。rclone 的日志会明确写出 HTTP 状态码。429 表示请求过于频繁服务端在限流。解决办法是降低并发--transfers 2 --checkers 4 --tpslimit 5--tpslimit 5把每秒请求数限制在 5 次能有效规避基于频率的限流。代价是慢但稳定比快重要。403 通常是授权过期。网盘侧的登录令牌有有效期过期后中间层会失去访问能力。这时候需要重新走一次授权流程把新的令牌更新到中间层配置里。5xx 一般是服务端临时故障重试就好。--retries 3配--retries-sleep 10s间隔递增重试比立刻连续重试有效得多。如果你挂的是不限速的套餐实际上传速度还是上不去那瓶颈多半在中间层本身或者是本机上行带宽。用iperf3之类的工具先测一下本机到目标网段的实际带宽再判断是不是工具的问题。5.5 排查速查表现象最可能的原因处理方式ls目录为空未挂载或进程已退出mount | grep 挂载点重启服务Permission denied用户不一致或 umask 过严检查挂载用户确认 allow-other文件名乱码编码不一致检查 locale用 convmv 转换上传中断并发过高被限流降 transfers、加 tpslimit授权失效返回 403令牌过期在中间层重新授权操作超时无响应缓存盘写满检查磁盘空间设置 cache-dir目录更新不及时dir-cache-time 过长临时手动刷新或缩短缓存时间大文件读取慢分片参数偏小调大 read-chunk-size6. 长期维护稳定比什么都重要6.1 凭证管理别偷懒整个链路里有三组凭证网盘本身的登录会话、中间层的 WebDAV 账号密码、rclone 配置文件里的混淆密码。我的做法是中间层使用的网盘授权令牌只存在中间层的配置文件里权限设成 600rclone 配置文件同样 600备份的时候把配置文件加密再传。听起来有点过度但一旦出问题清理成本远高于预防成本。chmod 600 /home/clouduser/.config/rclone/rclone.conf chmod 600 /srv/cloud-gateway/data/config.json别把这些文件放到 Web 服务器的静态目录下也别随手提交到代码仓库。国内有不少案例是因为配置文件泄露导致账号被异常登录的。6.2 加个健康检查别等出问题才知道挂载这种东西最怕的是看起来还在实际已经死了。加一个简单的健康检查脚本配合定时任务跑#!/usr/bin/env bash set -uo pipefail MOUNT/mnt/cloud LOG/var/log/rclone-health.log if ! mountpoint -q $MOUNT; then echo [$(date %F %T)] mount missing, restarting $LOG systemctl restart rclone-mount exit 0 fi if ! timeout 20 ls $MOUNT /dev/null 21; then echo [$(date %F %T)] mount unresponsive, remounting $LOG fusermount3 -uz $MOUNT 2/dev/null sleep 2 systemctl restart rclone-mount exit 0 fimountpoint -q判断挂载点是否存在timeout 20 ls判断是否还能正常响应。两个检查都通过就静默退出有问题就自动重启。放到 crontab 里每十分钟跑一次*/10 * * * * /usr/local/bin/rclone-health.sh这套自愈机制帮我省了无数个半夜爬起来处理的夜晚。要注意的是fusermount3 -uz是强制懒卸载正在写入的文件可能丢失部分数据。所以这个脚本适合处理已经卡死的情况而不是随便重启。6.3 多准备一手别把鸡蛋放一个篮子任何依赖第三方接口的方案都有失效风险。网盘侧改一次接口、中间层项目维护节奏一变整套链路就可能停摆。我的建议是第一关键数据保持本地完整副本。云盘是备份或者中转不是唯一存储。至少保证本地有一份能独立运行的数据。第二中间层不要只依赖一个项目。如果条件允许本地也装一个能提供 WebDAV 的通用文件服务作为对照组用来区分是网盘的问题还是是中间层的问题。第三配置文件定期导出。中间层的存储配置、rclone 的配置文件、备份脚本、systemd unit全部整理到一个目录里定期打包存一份。真出问题要重装的时候这份东西能让你半小时内恢复而不是重新看一遍文档。第四关注工具链本身的版本变化。rclone 从 1.x 版本一路升级过来挂载相关的参数有过调整比如 VFS 缓存模式的默认值、chunk size 的命名等。升级前先看 changelog别直接在生产环境上滚。关于杀毒和扫描这块如果你在挂载目录上跑安全扫描工具要特别注意扫描会触发大量随机读取在 FUSE 挂载上开销极大还可能因为并发过高被限流。建议把扫描范围限制在本地目录云端内容按需下载后再扫。最后分享一个我用了很久的小习惯给挂载点配一个 shell 别名减少手打出错。alias cdlcd /mnt/cloud alias clslls -lh /mnt/cloud alias cloudchecksystemctl status rclone-mount --no-pager | head -20挂载目录的路径偶尔会因为重构改来改去有个别名不用每次记路径。另外我会在/etc/motd里放一行提示说明这台机器的云盘挂载状态和检查命令接手的人不用翻文档就知道去哪看。这套方案我从单台树莓派一路用到机架服务器中间经历过令牌过期、容器崩掉、缓存盘写满、编码乱码各种状况但整体骨架一直没动过。把备份和健康检查做扎实日常使用其实相当无感——文件就在那儿cd进去就能用剩下的交给 systemd 和 crontab。