玩碧蓝航线的朋友，对 Alas 这个名字应该不陌生。这个开源自动化工具能把游戏里那些机械重复的日常操作接管过去，让脚本按计划跑图、收菜、做任务，省下来的时间可以用来做别的事。Alas 的更新频率在活跃期相当高，经常是今天刚适配了新活动，过两天又冒出一个小版本修 bug。但问题往往就出在“更新”这两个字上，默认从 GitHub 拉代码、从 PyPI 装依赖，在国内网络环境下经常会卡到怀疑人生。
这篇文章不是官方教程，也不是什么高深理论，就是我自己长期维护 Alas 时摸索出来的一套镜像源更新方案。我从 Git 同步、Python 依赖、Docker 部署三个层面分别做了处理，把踩过的坑和排错心得一并写了进去。无论你是刚接触 Alas 的新手，还是已经用了一段时间但每次更新都在跟网络斗智斗勇的老玩家，照着这套流程走一遍，基本能把更新这件事变得又快又稳。
1. 先搞清楚 Alas 更新到底做了什么
1.1 更新链条里的三个关键环节
Alas 的更新不是一个动作，而是一条链。很多人以为更新就是“拉到新代码就完事”，其实拉代码只是第一环。
第一环是代码本体。Alas 整个项目托管在 GitHub 仓库里，更新第一步自然是git pull，把最新 commit 拉到本地。这一步如果仓库很旧，可能会涉及大量文件变更，小文件一多，网络传输的压力就上来了。
第二环是 Python 依赖。Alas 是用 Python 写的，版本升级时经常会新增第三方库，这些依赖声明在根目录的requirements.txt里。如果你只拉代码不装依赖，启动时大概率会直接报ModuleNotFoundError。反过来说，有些版本会把某个依赖去掉，这时候如果不及时同步 requirements，就可能出现版本冲突。
第三环是配置和资源文件。像端口号、模拟器路径、账号信息这些用户配置，更新时一般不会动，但资源文件会变，比如关卡信息、船坞识别模板、脚本流程配置。这些文件虽然不显眼，却是最容易在更新后引发“行为异常”的地方。
所以完整的更新流程应该是：同步代码、更新依赖、检查配置和资源，最后才是重启服务。这套链条只要有一环走得慢或者出错，整个更新都会卡住。
1.2 为什么默认源经常卡住
先说明一下，我这里说的“卡住”纯粹是网络链路上的客观问题。GitHub、PyPI 官方源这些服务，服务器基本都架在海外，国内网络直连时 TCP 握手时延高，丢包率也偏高。Git 恰恰又是大量小文件并发传输的协议，一个包出错就会触发重传，重传到一定程度整个传输过程就陷入半死不活的状态。
我自己遇到过最典型的情况是：git clone跑到 80% 突然卡住，进度条不动，等了五分钟报fatal: early EOF。这种问题不是 Alas 本身的 bug，纯粹是传输链路太脆弱。PyPI 官方源也类似，安装依赖时经常是“正在下载”然后长时间没有动静，最后超时失败。
所以我的思路很直接：既然默认源不给力，那就把更新链路上能换的源全换成镜像源。镜像源本质上就是官方仓库在国内的同步副本，地址在国内，访问路径短，时延和丢包率都会好很多。
1.3 我的镜像源选型方案
这里先给出我的整体方案，后面章节再细节展开。
Git 仓库层面，我不建议用网上那些公共加速服务，而是自己用 Gitee 导一份镜像。公共加速服务的好与坏完全取决于别人的服务器状态，而且有时候会混入奇怪的历史 commit，安全性和稳定性都不好把控。自己导一份镜像到 Gitee，代码在自己账号下，速度稳定，出了问题也方便追查。
Python 依赖层面，我用的是清华 TUNA 的 PyPI 镜像，备用源是阿里云。清华镜像同步频率高，包比较全，适合安装 requirements.txt 里的依赖。阿里云则是备选，清华偶尔抽风或者某个包没同步的时候，切过去能救急。
Docker 部署层面，如果 Alas 是通过 Docker 跑的服务，我会给 Docker 配置 registry mirror 加速器。这个稍后会在 2.4 节详细说。
这套方案的核心逻辑是：不要把所有鸡蛋放在一个篮子里，每个环节选一个稳定源，同时留一个备选源。更新流程跑不通时，能快速替换而不是干等。
2. 镜像源怎么选，深入对比和避坑
2.1 常用镜像源速查表
先把常用的镜像源整理成一张表，方便对照查询。注意镜像源地址是会变的，尤其是 Docker 相关的镜像加速器，经常有服务调整甚至关停，使用前最好去各镜像站官网确认一下当前生效地址。
| 类型 | 推荐镜像源 | 配置地址示例 | 适用场景 | 备注 |
|---|---|---|---|---|
| Python / pip | 清华 TUNA | https://pypi.tuna.tsinghua.edu.cn/simple | requirements.txt 依赖安装 | 同步频率高，包比较全 |
| Python / pip | 阿里云 | https://mirrors.aliyun.com/pypi/simple | 清华不可用时的备用 | 速度也很快，但偶有同步延迟 |
| npm | npmmirror | https://registry.npmmirror.com | 前端工程依赖 | 老 taobao 域名已弃用，别再用 |
| Docker | 中科大镜像 | https://docker.mirrors.ustc.edu.cn | docker pull Docker Hub 镜像 | 地址可能有变动 |
| Docker | 网易镜像 | https://hub-mirror.c.163.com | docker pull Docker Hub 镜像 | 备选 |
| APT | 清华 / 阿里云 | https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ | Ubuntu 系统软件源 | 要匹配系统版本，如 jammy |
| Conda | 清华 | https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ | Conda 创建和管理 Python 环境 | 需要写入 .condarc |
这张表里的 pip 和 Docker 是 Alas 更新最常涉及的两类。npm 和 APT 属于锦上添花，如果你的系统本身就需要频繁装软件，顺手配置一下能省很多事。
2.2 pip 镜像的配置细节
pip 镜像配置有两种方式，一种是在命令行里临时指定，一种是写在配置文件里全局生效。我强烈建议用配置文件的方式，原因很简单：命令行临时指定容易忘，而且一旦你用了pip install但忘记带-i参数，pip 又会跑去官方源，网络一卡又是白等。
配置文件的位置分系统看。Windows 下是%APPDATA%\pip\pip.ini，通常就是C:\Users\你的用户名\AppData\Roaming\pip\pip.ini。Linux 下是~/.pip/pip.conf，也可以用系统级路径/etc/pip.conf。如果你不确定当前用的是哪个路径，直接执行下面这行命令，pip 会把当前生效的配置文件路径打印出来。
pip config list -v然后写入如下内容：
[global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple trusted-host = pypi.tuna.tsinghua.edu.cntrusted-host这一行是关键。清华镜像的 HTTPS 证书有时不被某些环境的 pip 信任，如果报 SSL 相关错误，这一行能帮你跳过证书校验环节。但注意，trusted-host本质上是在告诉 pip “我信任这个域名”，所以千万不要把别人提供的未知镜像源随便加进去，安全优先。
配置好之后，你可以用下面这行命令验证一下：
pip install --dry-run requests如果很快显示 “Would install requests”，说明镜像源配置生效了。
2.3 git 仓库的镜像思路：用 Gitee 建私人源
Git 仓库的镜像，我不太推荐用公共代理，而是建议在 Gitee 上导一份自己的仓库。Gitee 是国内老牌的 Git 托管平台，从 GitHub 导入仓库是它的内置功能，不需要你亲自先把仓库下载下来再传上去。
具体做法是：登录 Gitee，点击右上角的“ + ”号，选择“从 GitHub 导入仓库”。然后粘贴 Alas 的 GitHub 仓库地址，仓库名建议起成AzurLaneAutoScript-mirror这样的名字，方便自己一眼认出这是镜像。导入过程由 Gitee 服务器完成，你只需要等待即可。
导入完成后，你会得到一个类似https://gitee.com/你的用户名/AzurLaneAutoScript-mirror.git的地址。这就是你后续更新 Alas 时用的镜像源地址。
这里要注意一个问题：Gitee 导入的仓库默认不是自动同步的。也就是说，当你导入完那一刻，Gitee 上的代码和 GitHub 官方仓库是一致的，但之后官方仓库更新了，你的 Gitee 镜像并不知情。你需要每隔一段时间去 Gitee 仓库页面点一次“同步”按钮，或者用“强制同步”功能把 GitHub 上的最新 commit 拉过来。这一步是手动操作，没见过哪个 Gitee 按钮能完全自动化的，除非你自己写脚本调 API。
2.4 Docker 镜像加速器配置细节
如果 Alas 是用 Docker 部署的，那 Docker 镜像加速器就必须配好。Docker 默认从 Docker Hub 拉镜像，这个地址对国内网络同样不友好。配置加速器的核心文件是/etc/docker/daemon.json，如果文件不存在，创建一个即可。
{ "registry-mirrors": [ "https://docker.mirrors.ustc.edu.cn", "https://hub-mirror.c.163.com" ] }修改完成后重启 Docker 服务：
sudo systemctl restart docker之后执行：
docker info在输出里找 Registry Mirrors 这一项，如果能看到你配置的地址，说明加速器已经生效。然后随便拉一个镜像测试一下速度，比如docker pull hello-world，正常情况几秒钟就能下来。
还有一个隐藏坑：registry mirror 只对 Docker Hub 官方镜像生效。如果你拉的是ghcr.io、quay.io这类第三方仓库的镜像，镜像加速器是不起作用的。所以用 Docker 部署 Alas 之前，先确认它的镜像到底发布在哪个仓库，再决定要不要配加速器。
3. 实操：从零开始用镜像源更新 Alas
3.1 环境准备与前置检查
在动手之前，先检查三个东西：Git 是否安装、Python 版本是否合规、当前仓库是否干净。
Git 检查很简单：
git --version如果没有安装，Windows 用户建议装 Git for Windows，安装完记得把 Git 的 bin 目录加到 PATH 里。Python 检查执行：
python --versionAlas 对 Python 版本有要求，一般建议用 3.10 或 3.11，具体以仓库 README 的说明为准。如果当前版本太低，建议先升级 Python 再继续。第三步是检查本地仓库状态，进入 Alas 目录执行：
git status如果显示工作区有改动，一定要先处理，否则后面git pull会提示冲突。处理方式我建议先把改动 stash 起来：
git stash save "backup before update"这样既保留了你的改动，又把工作区恢复干净，方便拉取更新。
3.2 把 GitHub 仓库导入 Gitee
这一步提升速度的效果最明显。操作路径是：登录 Gitee -> 右上角“ + ” -> “从 GitHub 导入仓库”。在弹出的页面里粘贴 Alas 的 GitHub 仓库地址，然后点导入。
导入耗时取决于仓库大小和 Gitee 服务器的状态，Alas 这个仓库不算小，我等过大概一两分钟。导入完成后打开你自己的 Gitee 仓库，确认 code 页面能正常看到文件列表，然后复制 HTTPS 地址。
有一点要提醒：Gitee 导入的时候偶尔会把仓库的 issue、PR 这些也给带过来，但代码主体一般没问题。如果导入后仓库看起来缺了不少文件，别慌，多半是 Gitee 缓存问题，点一下仓库页面的“刷新”或者重新同步一次。
3.3 本地仓库切换镜像源并拉取更新
有两种情况。第一种是你之前还没有克隆过 Alas，那直接用 Gitee 地址克隆就行：
git clone https://gitee.com/你的用户名/AzurLaneAutoScript-mirror.git第二种是你本地已经有一个从 GitHub 克隆的老仓库，那不用重新克隆，直接改 remote 地址：
git remote set-url origin https://gitee.com/你的用户名/AzurLaneAutoScript-mirror.git改完之后执行git remote -v确认一下，输出里显示的 URL 应该已经变成 Gitee 地址。接下来就是拉取更新：
git fetch --all -p git pullfetch会把远端最新的 commit 信息拉到本地，但不会动你的工作区，这一步是安全的。pull则是把远程仓库的最新代码合并到当前分支。如果你之前已经 stash 了本地改动，此时大概率能顺利合并。
拉完以后看一眼版本号，可以用git log --oneline -5看最近几条提交，确认代码确实更新到了你要的版本。对比 Gitee 仓库页面上显示的 commit hash，如果一致说明同步成功。
3.4 用清华 PyPI 镜像安装依赖
代码同步完成之后，依赖这一环不能漏。进入 Alas 根目录，执行：
pip install -r requirements.txt如果你的 pip 已经按 2.2 节配置好了镜像源，这行命令就直接走清华镜像了，速度会明显快很多。如果你还没配置全局镜像，也可以临时指定：
pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple我见过很多人只拉代码、不装依赖，启动时看到ModuleNotFoundError: No module named 'xxx'，又花半小时排查。其实只要你每次更新后都跑一遍pip install -r requirements.txt，这类问题能少一大半。
如果安装过程中提示某些包找不到，比如Could not find a version that satisfies the requirement，大概率是清华镜像还没同步这个包的最新版本。这时可以临时加一个官方源兜底：
pip install -r requirements.txt --extra-index-url https://pypi.org/simple--extra-index-url的意思是“在原有源的基础上，额外增加一个官方源”。注意它是追加而不是替换，所以清华镜像优先，官方源补缺，这是最稳妥的兜底方案。
3.5 Docker 部署场景下的镜像更新流程
如果你是用 Docker 跑 Alas，代码和依赖的更新逻辑有点不同。镜像本身是打包好的，更新通常意味着拉取新的 image 版本并重新创建容器。
假设你已经配好了 2.4 节的 Docker registry mirror，那么更新流程是：
docker pull 你的镜像名镜像下载完成后，停掉旧容器、删掉旧容器、用新镜像重新创建容器。具体命令以你使用的镜像页面的说明为准，但有一个通用规则必须记住：容器里的数据是无状态的，杀掉就没了，所以一定要把配置、日志、数据库等目录通过 volume 挂载到宿主机上。比如：
docker run -d --name alas \ -v /你的宿主机路径/config:/app/config \ -v /你的宿主机路径/logs:/app/logs \ 你的镜像名这样更新时即使容器被删掉，数据也不会丢。我见过有人就是因为没挂载 volume，每次更新后重新创建容器，账号配置全没了，又得从头设置一遍。
3.6 更新完成后的启动与验证
代码和依赖都更新完之后，最后一步是启动验证。Alas 的启动方式根据版本不同略有差异，一般根目录会有main.py文件，可能是命令行入口，也可能有 GUI 窗口。还有的版本提供.bat或.sh启动脚本。以你当前版本 README 的说明为准。
启动后先别急着看界面，重点看日志输出。如果是正常启动，日志里会有一系列初始化信息，比如加载配置、连接模拟器、检查游戏进程。如果启动后立刻报错，多半是配置文件和代码存在不兼容。
这时候去查看 config 目录下的配置文件，看是不是缺了新版本要求的字段。很多时候官方在发布新版本时会新增配置项，旧配置里没有，程序启动时就抛异常。解决方法是打开配置文件，对比仓库里的配置文件模板，把缺失的字段补上。
如果补完配置还是报错，那就进入下一节的问题排查环节。
4. 常见问题与排错实录
4.1 问题速查表
这一节整理我在实际更新 Alas 过程中遇到过的典型问题，按表格形式列出，方便大家直接对照排查。
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
git pull报 uncommitted changes | 本地改过配置或代码，工作区不干净 | git stash保存改动，pull 后git stash pop |
pip install找不到某个包 | 镜像源同步延迟，或者包名/版本号有变 | 加--extra-index-url https://pypi.org/simple兜底 |
| SSL 证书校验失败 | 某些镜像源证书不被当前环境信任 | 在 pip 配置中加trusted-host |
docker pull长时间卡住 | 镜像加速器失效，或者拉的是第三方仓库镜像 | 确认 registry-mirrors 地址，检查docker info |
更新后启动报ModuleNotFoundError | 依赖没有同步安装 | 跑一遍pip install -r requirements.txt |
| Gitee 镜像仓库代码很旧 | Gitee 导入的仓库不会自动同步 | 去 Gitee 仓库页面手动点“同步” |
| 更新后游戏行为异常 | 资源文件或配置模板没同步 | 检查配置模板，删除旧缓存文件 |
| 本地仓库被改得乱七八糟 | 直接在主线分支改了代码 | 用git reset --hard回到远程版本 |
4.2 两个容易翻车的细节
第一个细节是 pip 镜像的“全局配置依赖”。很多人把 pip 镜像写进全局配置后，每次安装都成功了，就觉得很稳妥。但如果你换了网络环境，比如从家里切换到公司内网，内网通常访问不了公网镜像源，这时候 pip 就会一直连接超时。遇到这种情况，临时用命令行参数覆盖全局配置：
pip install -r requirements.txt --index-url https://pypi.org/simple --trusted-host pypi.org别嫌麻烦，这比卡在超时里等十分钟强得多。
第二个细节是git pull和配置文件冲突。Alas 的很多配置文件，比如config/目录下的文件，本身就在 git 仓库里被跟踪。你有两种选择：要么把配置文件从 git 跟踪里移除，改为用本地副本；要么每次更新前都把配置改动 stash 起来，更新后再 pop。我个人的习惯是配置文件和源码分开存放，把源码目录保持纯净，配置文件放到单独目录，这样更新时可以直接git reset --hard，完全不用怕冲突。
4.3 排错思路总结
排错时我习惯从底层往上层排查。先看网络层，用curl测试一下镜像源地址通不通；再看代码层，git status确认工作区是否干净；然后是依赖层，直接import一下报错的模块，看是没安装还是安装版本不对；最后才是配置层，检查配置模板和实际配置的差异。
举个例子，有一次更新后模拟器一直连接失败，我第一反应是模拟器端口设置问题，检查半天发现不是。后来用git diff看了一眼更新前后的配置文件，发现新版本把 ADB 连接模式从connect改成了pair，端口逻辑完全变了。这种问题只有把镜像源和代码版本对比起来看才能发现。
5. 一些我踩过坑之后留下的习惯
5.1 更新前先做版本快照
现在每次更新 Alas，我都会先记录当前 commit hash。这一步很简单：
git rev-parse HEAD > version.txt然后把更新前能正常运行的版本号随手存起来。万一新版本出现重大问题，想回退就很方便：
git reset --hard 之前记录的那个hash有了这个快照，心里就有底了，更新后就算翻车也能快速恢复，不用在那干瞪眼。
5.2 让镜像源“活”起来
Gitee 镜像不是导一次就完事的。官方仓库每次发新版本，Gitee 上的镜像不会自动跟着变，需要你去手动同步。我习惯在官方仓库 release 出通告之后，先去 Gitee 点一下同步按钮，等同步完成，再在本地拉更新。这样本地拉到的永远是最新的，不会被“Gitee 仓库还停留在旧版本”这种问题坑到。
如果你嫌手动麻烦，可以写个简单的定时任务，每天自动去 Gitee 仓库触发同步。操作不难，但要注意别触发太频繁，Gitee 对同步频次有些限制。
5.3 保留一个纯净的本地副本
我的开发机上保留了两份 Alas。一份是纯净的源码副本，只用来拉更新、看日志、做对比，这份目录永远保持干净，不跑实际任务。另一份是实际的运行副本，配置文件、账号数据都在这里。
这样做的好处很明显：纯净副本可以随时git reset --hard回退到任意版本，脏东西不会影响主运行环境。遇到新版本 bug，我在纯净副本里先测一轮，确认没问题再同步到运行副本，相当于多了一道保险。
最后再分享一个小经验：更新这件事，工具是死的，人是活的。镜像源只是帮你把网络这层障碍扫平，真正决定更新顺不顺的，是你对 Alas 更新机制的理解深度。把这套流程跑顺之后，每次大版本更新我从开始到搞定基本五分钟内完成，希望这篇也能让你省下那半小时干等更新的时间。
