第一次折腾 Alist 的起因很朴素：手上三台设备、两个网盘账号、一块挂在路由器上的移动硬盘，找一份文档得先回忆它到底躺在哪儿。Alist 恰好就是治这个毛病的工具——它本身不存文件，本质是一层“目录聚合”，把本地目录、各类云盘、WebDAV 服务、对象存储统统挂到同一个网页界面下，浏览器打开就是一棵统一的目录树，点开能预览、能下载、能上传、能生成带提取码的分享链接。这篇教程写给完全没碰过 Alist 的人，从“它到底是什么”讲到“怎么部署、怎么挂载、怎么把文件真正下下来”，也包括我这一年多踩过的坑：容器重启后配置全丢、目录能看但文件下不动、大文件下到 90% 断流、前置转发没配对导致 502 之类。看完你应该能从零把一套可用的文件聚合站跑起来，并且知道出问题时该往哪儿看。

1. 先把 Alist 的定位掰扯清楚：它不是网盘，是目录聚合层

1.1 一句话讲透：Alist 存的是“路径映射”，不是文件

很多人第一次装完 Alist，往界面上传了个文件，发现服务器硬盘空间没变化，就以为哪里配错了。其实这是对它的定位有误解。Alist 在数据库里存的东西非常轻——主要是存储驱动类型、挂载路径、认证凭据、权限规则这些配置项，真正的文件内容仍然躺在你挂载的那个源上。你从网页点下载，它的动作是“拿着配置里的凭据去问源要文件，然后把流转给浏览器”，中间不落盘。

这个设计带来两个直接后果，必须提前想明白。第一，源端删了文件，Alist 这边立刻跟着消失，因为它只是索引层，不存在“同步”这回事；第二，源端的账号失效，挂载点直接红掉，界面打不开文件，但 Alist 自己的配置一点没少，重新授权就能恢复。理解这两点，后面遇到“文件凭空不见”就不会乱。

生活化的类比：Alist 更像一个给你家所有储物柜装了统一标签和统一门牌的管理员，你告诉他“A 柜在厨房、B 柜在阳台”，他负责指路和开锁，柜子本身不是他造的。

1.2 五类存储挂上去之后，实际体验差在哪

不同存储挂到 Alist 之后，体验不是一回事。我按实际用下来的体感排了个表，这个差异直接决定你该把重要文件放在哪类源上：

本地目录和对象存储这两类是“你想怎么用就怎么用”的类型，速度、权限、稳定性都可控；公共云盘类最省事但也最磨人，因为授权令牌会过期、下载会有频率限制、大文件可能被拦。我的建议很直接：核心资料放本地或对象存储，云盘只作为“存量资料访问入口”，别把唯一副本押在云盘挂载上。

1.3 2025 年选版本：主线版本与几个必知现状

Alist 走的是 v3 主线，目前更新节奏不算激进，主要是驱动适配和细节修补。选版本有两条经验：

• 生产环境用固定版本号，别用 latest。latest 意味着某天你重启容器，拉下来一个新版本，驱动行为变了、配置字段挪了，站直接挂。我吃过这个亏，后来 compose 文件里一律写死v3.x.x。
• 升级前必须备份 data 目录。v3 系列跨大版本升级时，数据库结构偶尔会有迁移，回滚没备份就只能重配所有存储，挂载十几个源的话这活儿能干一下午。

另外一个现状值得知道：这类开源项目社区活跃，会有第三方镜像、第三方前端主题、第三方驱动插件。只从项目官方仓库和官方文档给出的地址取东西，第三方构建的镜像里塞了什么你没法审计，尤其是涉及凭据的项目，风险不成比例。

1.4 三类人不适合装 Alist（提前劝退）

写教程的惯例是只讲好处，我觉得该说清楚它不适合谁，省得白折腾：

第一类，只想同步文件的人。Alist 不是同步盘，它没有双向同步、没有冲突合并、没有本地客户端常驻。你要的是文件在多台设备间自动保持一致，那方向完全不对。

第二类，指望它给云盘提速的人。挂载公共云盘后，下载速度的上限在对端手里，Alist 只是转发。如果源本身限速，你换什么前端都没用，反而因为多了一跳，速度可能更差。

第三类，只有一台电脑、文件都在这台电脑上的人。装个 everything 之类的本地搜索工具比部署一套 Web 服务划算得多。

反过来说，如果你有“多源聚合 + 跨设备浏览器访问 + 想给朋友发个带密码的下载页”这三个需求里的任意两个，Alist 就值得装。

2. 部署方式选型：容器、裸机、面板，各自的代价

2.1 机器怎么挑：CPU 不是瓶颈，上行带宽和磁盘 IO 才是

先破除一个常见误区：Alist 本体极轻，一个 1 核 1G 的小机器跑起来毫无压力，内存占用长期在几十兆到一百多兆。真正决定体验的是三样东西：

上行带宽。所有经过服务器中转的下载都吃上行。你家宽带上行 30Mbps，那同时两个人下载就会互相拖慢；如果是云服务器，注意很多入门款标的是“峰值带宽”，跑满会限速。这是最容易在部署完才发现的问题。

磁盘 IO。挂载本地目录时，机械盘随机读大量小文件会很慢，尤其是相册类目录生成缩略图的时候。固态是明显更好的选择。

网络位置。挂在云上的机器访问对象存储通常比家里宽带快，但访问你家 NAS 就绕远了。把 Alist 部署在离你的主要存储最近的地方，这个原则比配置什么参数都管用。

最低配置我给个参考：1 核 1G、10G 系统盘，够跑本体加轻量使用；如果要开离线下载、要缓存缩略图、要同时多人访问，2 核 2G 起更从容。

2.2 Docker 落地全流程（含 compose 与端口映射）

容器是最省心的路子，因为它把依赖和环境变量都封好了。先确认机器上有 Docker 和 compose 插件：

docker --version docker compose version

然后建目录、写 compose 文件。我习惯把配置放在/opt/alist，这样备份就是打包一个目录的事：

mkdir -p /opt/alist/data cd /opt/alist

docker-compose.yml内容大致如下（镜像名以你实际拉取的官方镜像为准，这里用占位）：

services: alist: image: alist:latest container_name: alist restart: always ports: - "5244:5244" volumes: - /opt/alist/data:/opt/alist/data - /mnt/disk1:/data/disk1 environment: - PUID=0 - PGID=0 - UMASK=022 logging: driver: json-file options: max-size: "10m" max-file: "3"

几个参数值得单独说。端口映射5244:5244，左边是宿主机端口，如果你想用 8080 对外，写成8080:5244，容器内部不用改。数据卷/opt/alist/data这一行是命门，不映射的话容器一删配置全没，这是新手第一大坑。第二行卷/mnt/disk1是把宿主机的实际目录喂给容器，后面挂载本地存储时必须填容器内路径/data/disk1而不是宿主机路径，这个区分后面还会细讲。日志限制是我自己加的，不加的话日志文件能涨到几个 G 把盘吃满。

启动并看日志：

docker compose up -d docker logs -f alist

日志里会打印初始管理员密码，可能是一串随机字符。拿到之后浏览器访问http://你的IP:5244就能看到登录入口。如果打不开，先确认防火墙和安全组放行了端口，这一步卡住的人特别多。

2.3 裸机二进制 + systemd 托管

不想装 Docker，或者机器性能实在太弱，可以用二进制。下载对应架构的压缩包，解压到一个固定目录，比如/opt/alist，然后给它建个服务单元：

sudo tee /etc/systemd/system/alist.service > /dev/null <<'EOF' [Unit] Description=Alist service After=network.target [Service] Type=simple WorkingDirectory=/opt/alist ExecStart=/opt/alist/alist server Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target EOF

然后systemctl daemon-reload && systemctl enable --now alist。二进制方式的好处是资源占用更低、排错时能直接看到前台输出；坏处是升级要手动替换文件、依赖系统的 glibc 版本，某些精简系统上会报找不到库。

忘了密码的话，二进制方式在程序目录执行./alist admin set 新密码就能重设；容器方式则是docker exec -it alist ./alist admin set 新密码。这两条命令建议记下来，比翻文档快。

2.4 部署阶段最容易翻车的四个点

按我遇到的频率排序：

一、data 目录没做持久化。容器重建后登录不进去，提示密码错误，其实是数据库被重置了。判断方法：docker inspect看 Mounts 里有没有 data 目录的映射。

二、宿主机端口被占。启动报 bind 错误，或者容器起来了但访问是另一个服务的页面。用ss -lntp | grep 5244确认端口归属，改成别的宿主端口即可。

三、权限问题导致写入失败。容器里以非 root 用户跑，挂载的宿主机目录属主不对，表现为上传文件失败、缩略图生成失败。可以临时用PUID=0 PGID=0排除，确认是权限问题后再改成正确的 UID/GID。

四、系统时间不同步。表现很奇怪：登录后马上掉线、令牌校验失败。原因是一些凭据的签名带时间戳，机器时间偏几分钟就全乱。timedatectl看一下，把时间同步服务打开。

3. 第一次登录后台：必做的初始化动作清单

3.1 初始密码从哪来，以及为什么必须立刻改

初始密码有两个来源：一是首次启动时控制台输出的随机串，二是你手动用admin set指定的。登进去第一件事就是改密码，路径在“用户”里编辑 admin 账号。这不是形式主义——Alist 的默认管理端口 5244 是公开且可被扫描的，用默认端口加弱密码，等于把整个文件树挂在外面。

改完密码之后，我还会顺手做两件事。一是把默认端口改掉，虽然改端口不算安全措施，但能过滤掉绝大多数无差别扫描流量，日志会清爽很多。二是先把“访客”账号的权限降下来，Alist 默认给访客的权限包括列目录和下载，如果你的站点要对外开放，这个默认值会让你所有挂载点对陌生人是可读的。在用户管理里把访客的“读取”按需保留，“写入”“删除”一律关掉。

3.2 存储列表界面里每个字段的含义

进后台点“存储”，添加时会出现一堆字段，第一次看很容易懵。核心的几个：

挂载路径。这是 Alist 对外暴露的虚拟路径，比如填/docs，那网页上就多出一个docs目录。可以填/作为根目录，但只能有一个存储占根，多个存储都想挂根上的话，用不同的一级路径区分。挂载路径不能重复，重复了保存会报错。

根文件夹 ID。这个字段是新手最容易出错的地方。它指的是“从源的哪个子目录开始映射”。本地存储和 WebDAV 一般填/或者留空表示从根开始；云盘类往往要填一串目录 ID，需要先在源里定位到那个目录再复制 ID。填错的典型症状是：挂载显示“工作状态正常”，但点进去是空目录。

Web 转发与重定向策略。这三个选项决定下载时数据怎么走。选“重定向”时，浏览器会拿到源的真实地址，自己去下载，服务器不承担流量，速度快且省带宽；选“本地转发”时，所有数据经服务器中转，好处是能掩盖源地址、能配合访问控制，坏处是吃服务器的上行带宽。公共云盘如果没有可直连的地址，只能用转发，这时候服务器的带宽就是硬上限。

缓存过期时间。目录列表的缓存时长。设太小，每次进目录都要去问源，慢且容易被限流；设太大，源端新增文件后要等一会儿才显示。我一般给 30 分钟。

3.3 站点设置：站点 URL、路径前缀、隐藏规则

站点设置里有几个会直接影响能否正常使用的项：

站点 URL。填你最终访问用的完整地址，比如https://files.example.com。不填或填错，分享链接会生成错误的域名，别人点开是空的。改过域名之后一定要回来同步改这一项，我因为这个排查过半小时。

路径前缀。如果你打算把 Alist 挂在某个子路径下（比如https://example.com/alist），这里要填/alist，同时前置转发那边也要做对应处理。一般建议直接用子域名而不是子路径，省掉一堆静态资源路径不匹配的问题。

隐藏文件规则。可以按文件名匹配隐藏特定文件，也支持用正则。我通常把*.tmp、*.log、Thumbs.db这类加进去，目录看起来干净不少。

允许索引与分页。目录里文件多的时候，一页全加载会很卡。把每页数量控制在 100 到 200 之间比较舒服。

3.4 data 目录里到底存了什么，怎么备份

data目录是全部家当，里面有：数据库文件（存所有配置，包括存储凭据）、配置文件、日志目录。备份就三步：

# 停容器保证数据库一致 docker compose stop alist # 打包，注意排除日志省空间 tar -czf /backup/alist-$(date +%F).tar.gz -C /opt/alist data --exclude='data/log' docker compose start alist

备份频率我定在“每次改动配置之后 + 每周一次”。因为配置的改动往往是不可逆的（删了存储要重新拿令牌、重新找根目录 ID），而文件本身你在源端还有。备份里包含明文凭据，别往公开网盘扔，加密压缩或者放本地。

迁移到新机器也是同样思路：新机器装好程序，把 data 目录解出来放回去，启动即可，端口、账号、挂载全部原样。这一点比很多同类工具省事。

4. 挂载实操：四类存储从零配到能用

4.1 挂载路径的规则与常见误配

在动手挂之前，先定一个路径规划。我的习惯是这样：

/ 根目录（放一个说明性质的本地目录） /media 影音 /docs 文档 /team 团队共享（对象存储） /legacy 存量云盘资料

规则上要注意三点。路径区分大小写，/Docs和/docs是两个不同的挂载点，混用会让访问 404。路径不要带空格和中文，虽然程序大多能处理，但一旦进了分享链接、进了其他客户端挂载，转义问题会一层层冒出来。挂载顺序有讲究，多个存储挂在同一个父路径下时，按“排序”字段从小到大排列，改完要刷新。

还有一个隐蔽的坑：同一个路径不要既挂了存储又建了同名目录。这种情况下目录内容会互相干扰，表现为文件列表里出现重复项或者访问时好时坏。

4.2 本地目录挂载：容器路径映射是关键

这一步是把机器上的实际目录接进来。假设宿主机上有个/mnt/disk1/movies，compose 里已经写了- /mnt/disk1:/data/disk1的映射，那么在 Alist 后台的“根文件夹路径”要填/data/disk1/movies，不是/mnt/disk1/movies。

这个区别是容器部署里最高频的错误。因为 Alist 运行在容器内部，它眼里的文件系统是容器自己的，宿主机路径它根本不认识。填错的症状很好认：挂载状态显示正常，点进去提示目录不存在或者空的。

配置项填法参考：

如果你确定路径写对了还是空的，直接进容器验证：

docker exec -it alist ls -la /data/disk1/movies

能列出来说明容器内路径没问题，问题在 Alist 的配置；列不出来说明映射本身没生效，回去检查 compose 的 volumes。

4.3 WebDAV 挂载：五个参数逐项拆解

WebDAV 是很通用的协议，很多 NAS 和小型服务都提供。挂载时需要的信息就五样：

地址。填到目录层级，比如https://dav.example.com/remote.php/dav/files/user。注意不要漏掉协议头，也不要多写结尾斜杠（有些服务端对结尾斜杠敏感）。

用户名 / 密码。有些服务要求用“应用专用密码”而不是登录密码，生成方式在对方后台找。

根文件夹路径。如果地址已经指到了具体目录，这里填/即可。

WebDAV 策略。三个选项的实际区别：

• 重定向：优先用，浏览器直连源，服务器不背流量
• 本地转发：源不支持直连或者需要隐藏源地址时用
• 使用服务器转发并缓存：适合小文件高频访问

我实测下来，绝大多数情况下选“重定向”体验最好。但如果你的前置转发没做好 HTTPS，重定向会把用户带到http://的源地址上，浏览器可能拦截，这时候退回“本地转发”。

搭完之后验证一下：

curl -u 用户名:密码 -X PROPFIND https://dav.example.com/ -H "Depth: 1" -i

返回 207 说明协议层通了，返回 401 是凭据问题，返回 404 是路径问题，返回 501 是对端没开 WebDAV 支持。

4.4 S3 兼容对象存储：endpoint 填错是最常见的事故

对象存储的好处是天然适合大量文件、天然支持直链、几乎不用担心限流。挂载时要填的字段：

Endpoint 这一项踩坑最多。有些服务商给的控制台地址和 API 地址不是同一个，你在浏览器里打开的域名未必能用于 API 调用。正确做法是去官方文档里找“S3 兼容访问地址”那一栏。另外注意有些服务要求路径风格（path-style）访问，需要在存储配置里把对应开关打开，否则会报找不到桶。

凭据方面，强烈建议单独建一个只有读写指定桶权限的子账号，别用主账号密钥。主账号密钥泄露等于整个云账号沦陷，而 Alist 的数据库里是明文存这些凭据的。

4.5 云盘类挂载：令牌、根目录 ID 与限速现实

这一类挂载的流程通常是：选择对应驱动 → 按提示走授权 → 拿到刷新令牌 → 填入 → 填根目录 ID。几个关键认知：

令牌会过期。有些服务的刷新令牌有效期是几个月，到期后挂载点会突然报错，症状是“目录列表为空”或者“获取文件失败”。这不是配置坏了，重新走一遍授权、把新令牌贴进去就行。所以我建议给每个挂载点写个备注，记录授权日期，到期前主动换。

根目录 ID 一定要填对。拿根目录 ID 的方式通常是：在网页版打开那个目录，看地址栏里的一串字符，或者用第三方工具列目录获取。填root、/、留空这些做法在不同驱动上行为不一致，按官方文档来。

限速是常态。这类源通常对第三方客户端有频率限制，表现为：连续下载几个文件后开始报错，等一会儿又好了。应对办法是降低并发、把缓存时间调长、避免用它做大批量文件迁移。

别把重要文件只存在这类源上。授权随时可能因为各种原因失效，而一旦失效你连文件都访问不了，只能去官方客户端里操作。这是我用下来最实在的一条经验。

5. 下载与分享链路的真实表现：从能打开到能下完

5.1 一次"目录能看、文件下不动"的完整排查记录

这是最典型的一类故障，我把当时的排查顺序完整记下来，你可以照着走。

现象：某个云盘挂载点，目录树正常展开，文件名、大小、修改时间都对，点某个文件下载，浏览器转圈几秒后报错，或者下载出 0 字节文件。

第一步，看 Alist 日志。

docker logs --tail 200 alist | grep -i error

日志里如果出现上游返回的状态码（401、403、429），基本能定性。401 是凭据失效，403 是权限或防盗链，429 是频率限制。这一步能解决八成问题，别跳过。

第二步，确认存储状态。后台存储列表里每个条目右侧有状态标识，如果显示异常，点“编辑”再点保存会触发重新连接，很多时候状态就恢复了。

第三步，确认根目录 ID。如果日志里是 404，多半是根目录 ID 指向的目录已经不存在或者被改名了。

第四步，换 WebDAV 策略试。把“重定向”改成“本地转发”，再点下载。如果转发能下、重定向不能下，说明是生成的真实地址有问题（可能是地址里的签名参数过期，或者源的直链需要特定请求头）。这个对比测试非常有效，一步就能定位问题在“地址生成”还是“链路本身”。

第五步，绕过浏览器直接用命令行验证。

curl -I "http://127.0.0.1:5244/d/挂载路径/文件名"

看返回的状态码和 Location 头。如果 Location 指向一个明显不对的域名，比如内网地址或者 http 地址，那就是站点 URL 配错了，或者前置转发没传对 Host 头。

第六步，检查隐藏规则和小写转换。有些隐藏规则写得太宽，把目标文件也匹配进去了，表现是文件在列表里能看到（因为列表用的是源返回的原始数据）但下载时被拦。

按这六步走下来，我遇到过的下载失败基本都能定位。特别提醒：别一上来就重装、就删存储重建，那会把排查线索一起删掉。

5.2 直链、分享页、临时链接三者区别

Alist 提供的访问形式有三种，用途完全不同：

直链。形如http://你的域名/d/挂载路径/文件名，直接指向文件。它需要登录态或者该路径对访客开放，适合自己用下载工具拉取。用多线程下载工具挂这个地址，比浏览器单线程快很多，尤其是大文件。

分享页。在文件上创建分享，生成形如http://你的域名/s/xxxx的地址，可以设置提取码和有效期。打开是一个带样式的下载页面，适合发给别人。分享页背后的实际下载仍然走直链逻辑，所以如果直链本身有问题，分享页也一样下不动。

临时链接。部分驱动会生成带签名的临时地址，有效期通常很短（几分钟到几小时）。这类链接不能长期保存，复制出去过一会儿就失效，别拿它做长期引用。

三者的选择逻辑很简单：自己用走直链配下载工具；发给不懂技术的人走分享页配提取码；临时给别人看一眼走临时链接，但要说清楚时效。

5.3 大文件下载中断的三个诱因与对应改法

下到 90% 断流是最让人抓狂的。我归了三类原因：

一、前置转发超时。请求经过 Nginx 之类的前置服务时，默认的读超时可能只有 60 秒。大文件传输过程中如果有一段时间没有数据流动（比如源端在慢慢吐数据），连接就被掐了。改法是在前置配置里把读超时和发送超时都调大，同时关掉响应缓冲：

proxy_read_timeout 3600s; proxy_send_timeout 3600s; proxy_buffering off;

二、服务器内存被缓冲吃满。开着响应缓冲时，Nginx 会把上游数据先攒在内存或临时文件里，大文件直接把内存打爆，进程被系统杀掉。上面那条proxy_buffering off就是治这个的。

三、源端断流。云盘类源在大文件传输时可能中途停止响应。这种只能靠下载工具的重试和断点续传能力扛过去。所以大文件一律用支持断点续传的下载工具，不要用浏览器直接下，浏览器断了就得从头来。

顺带一提，如果你用命令行拉大文件，curl -C -可以续传，配合--retry参数能自动重试，比手动点强得多。

5.4 在线预览依赖什么，为什么有的文件点不开

预览能不能用，取决于两件事：文件类型是否在支持列表里，以及浏览器能不能直接渲染。

图片、纯文本、PDF、常见视频格式一般是直接能开的。视频预览还额外依赖浏览器的解码能力，某些编码格式（比如一些不常见的音频编码）浏览器解不了，表现是能播放但没声音，或者直接黑屏。这不是 Alist 的问题。

Office 文档类的预览，通常需要额外的组件或者转成 PDF，纯前端方案效果有限。如果你很在意这块，思路是让源端提供转换能力，或者干脆把要分享的文档导成 PDF 再放上去。

音频和视频的拖动进度条体验，取决于源是否支持 Range 请求。本地存储和对象存储基本都支持，可以随意拖；部分云盘源不支持 Range，表现是一拖动就从头开始缓冲。这个差异在配置阶段看不出来，得实际用才知道。

6. 前置转发、访问控制与长期维护

6.1 Nginx 前置转发的配置要点

直接用 IP 加端口访问体验很差，也不安全。套一层前置转发，配上 HTTPS，是标准做法。配置要点：

server { listen 443 ssl http2; server_name files.example.com; ssl_certificate /etc/ssl/certs/files.pem; ssl_certificate_key /etc/ssl/private/files.key; client_max_body_size 0; location / { proxy_pass http://127.0.0.1:5244; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 3600s; proxy_send_timeout 3600s; proxy_buffering off; } }

逐条解释几个关键项。client_max_body_size 0表示不限制上传大小，不设的话默认 1M，传大文件直接 413。Host头必须透传，否则 Alist 生成的分享链接会用内部地址。X-Forwarded-Proto让后端知道外部是 HTTPS，生成的链接才会是 https。Upgrade和Connection是为了支持一些需要长连接的交互。超时和缓冲前面讲过，大文件必备。

配完之后一定要从外网实际访问一次，检查页面里的资源加载地址是不是 HTTPS、分享链接域名对不对。只看“能打开”不够。

6.2 访客权限与目录密码

如果这个站要对外开放，权限设计要有层次。我的做法是三层：

公开层。只有一两个目录对外，内容是明确可以公开的素材、说明文档。通过“元信息”里的密码或者隐藏规则控制，访客账号只给读。

受限层。需要密码才能进。Alist 支持给目录单独设密码，在元信息里配置。注意这个密码是页面级的，不是账号级的，适合发给特定的人。

私有层。只有 admin 能看，访客账号完全不可读。这类目录我建议连挂载点都别暴露给访客，直接在存储配置里把权限收紧。

有个细节容易忽略：访客能看到的目录树是聚合的，某个父级目录设了密码，子目录的直接链接仍然可能绕过。所以敏感内容别放在公开目录的子路径下，单独挂到另一个一级路径上更保险。

6.3 升级与回滚：别在没备份时点更新

升级流程我固定成这个顺序，一次没出过事：

1. 记录当前版本号
2. 停服务，备份 data 目录
3. 拉新镜像或替换二进制
4. 启动，登录检查
5. 逐个点开存储，确认状态正常
6. 随便下一个小文件验证链路
7. 有问题立刻回退到备份的 data 加旧版本

其中第 5 步和第 6 步不能省。有过一次升级后界面正常、登录正常，但某个驱动的字段名变了，导致那个挂载点默默失效，三天后才发现。升级后逐项验证比升级本身更重要。

6.4 我长期跑下来攒的几条习惯

最后分享几条实操习惯，都是踩坑换来的。

给每个挂载点写备注。备注里写清授权日期、凭据来源、根目录 ID 是怎么拿到的。半年后你再回来看，没有备注基本等于重新摸索一遍。

日志留一份在外部。容器日志跟着容器走，容器删了就没了。把日志目录映射出来，或者定期导一份，出问题时能回溯。

别在一个实例上挂太多源。听起来很爽，实际上一个源出问题会影响整体体验（比如某个驱动卡住导致目录加载慢）。我现在的做法是分成两个实例，一个放可靠的本地和对象存储，一个专门放各类云盘，互不干扰。

监控端口和磁盘。磁盘满是最隐蔽的故障，表现是上传失败、缩略图生成不出来、数据库写入报错。加个简单的磁盘阈值告警，能省掉很多莫名其妙的排查。

定期做一次恢复演练。备份不验证等于没有备份。我会每隔几个月把备份解到一台测试机上跑一遍，确认账号能登、存储能读。这个习惯救过我一次——某次发现备份脚本里的排除规则把数据库文件也排除掉了。

这一年多用下来，Alist 最让我满意的地方不是功能多，而是它的“薄”——它不试图接管你的文件，只负责把散落各处的入口收拢成一张地图。也正因为薄，出问题时排查路径很清晰：先看日志，再看存储状态，再看链路，最后看前置转发。反过来，最需要警惕的也是这一点：它不会帮你保住数据，源端没了就是没了，所以凡是你觉得重要的东西，至少保证有一份不在任何需要授权才能访问的地方。至于配置本身，我更倾向于“少即是多”——挂三五个真正在用的源，把每个都调通、写清备注、定期验证，比挂二十个半死不活的挂载点要舒服得多。