挺久没写 Alas 相关的内容了结果昨天群里又有人被更新折磨了一晚上Alas 弹出新版本提示GitHub 上下载包卡在 4%换了几个网络环境都一样最后跑来问我到底怎么用镜像源更新 Alas。这个场景我太熟悉了我自己早年也被这么卡过。Alas 是碧蓝航线圈子里用得很多的自动化脚本更新频率不低每次更新都涉及两件事拉取脚本本体、安装 Python 依赖。这两件事在国内网络环境下都容易出问题但只要把镜像源用对整个更新流程可以从“挂着睡觉”变成“十分钟收工”。这篇文章就把我实际跑通的镜像源更新流程完整写下来覆盖为什么要更新、卡在哪个环节、怎么配置 GitHub 加速下载、怎么配 pip/conda 镜像源以及更新过程中最容易翻车的配置文件迁移问题。无论你是刚装好 Alas 的新手还是被直连更新劝退过的老用户照着做基本都能顺利更新。1. 为什么要关注 Alas 更新版本迭代与直连下载的现实问题1.1 新版本到底更新了什么Alas 的维护者更新节奏不算慢这不是在刷版本号玩。新版本里实际包含三类东西游戏数据适配新活动图、新海域、新船掉落识别、地图路线坐标的更新。游戏客户端每次大更新脚本的识别数据大概率要跟着动。脚本逻辑修正自动出击调度、石油/弹药控制逻辑、任务队列优先级的调整这类改动直接影响挂机效率。依赖包变更某个功能模块重写之后requirements.txt 里会新增或替换 Python 库。你如果只看脚本本体不更新依赖启动时就会直接报 ModuleNotFoundError。所以并不是“能用就别动”。活动图识别不了、掉落判断错乱、界面提示版本过旧都是不更新会遇到的典型问题。更麻烦的是如果你跳过的版本太多配置文件格式跨度过大升级时迁移脚本要处理的东西更多反而更容易出幺蛾子。我的建议是小版本跟随更新别攒太久。1.2 直连更新时的典型卡死症状先说说我见过的几种典型症状你可以对照一下自己属于哪种症状具体表现根因git pull 卡住不动长期停在 Resolving deltas 阶段进度条也不走git 协议交互在 GitHub 上不稳定压缩包下载中断下载到一半断掉重试后进度清零重来境外文件节点连接被重置pip 安装卡住Collecting 阶段一直转圈最后超时PyPI 默认源服务器在国外conda 环境解析失败Solving environment 卡十几分钟conda 默认通道访问慢这里要说明一句这些症状未必是你的网络“有问题”而是这些境外站点在国内的连接质量本身就是忽快忽慢。页面前端能打开不代表背后的大文件下载链路也顺畅git 这种小包高频交互的协议比单纯下载文件更容易被卡住。所以解决思路不是反复重试而是把下载链路整体切换到国内能稳定访问的镜像源上。2. 拆解更新链路里的两个瓶颈脚本本体和依赖包仓库2.1 为什么 GitHub 直连下载这么不靠谱要理解镜像源为什么有用先得知道卡在哪。Alas 的更新链路其实分两段第一段是从 GitHub 拉取脚本本体。GitHub 的网页和 git 交互走的是 github.com但 release 的压缩包实际是重定向到 objects.githubusercontent.com 这类对象存储 CDN国内连这两个域的体验差别很大。很多时候你打开 GitHub 的 Release 页面很快但一点下载链接就转圈就是这个原因。对于 git clone 和 git pull 来说卡顿原因更隐蔽。git 在传输时会先交互大量小包做协议握手、对象枚举、delta 计算这个过程对连接质量极其敏感。Alas 仓库的文件量不算特别巨大但历史提交多了之后git 需要交换的对象也不少一旦网络抖动就会长期停在 Resolving deltas。我见过不少人以为是自己仓库坏了反复删除重来实际上换条通道就好了。2.2 为什么装依赖也会跟着卡第二段瓶颈是 Python 包仓库。Alas 启动依赖大量第三方库更新脚本时如果 requirements.txt 变了就需要用 pip 重新安装。pip 默认的 index-url 指向 pypi.org服务器在海外。国内直连时光是解析包元数据就能等半天下载大一点的包更是折磨。如果是用 conda 管理的环境默认的 channels 也在海外依赖解析速度一样感人。这里可以打个比方你把 Alas 更新想象成施工队进场干活脚本本体是施工图Python 依赖是建材。图纸下载得再快建材仓库在万里之外卡车一趟趟堵在路上工地照样开工不了。所以只用 GitHub 加速还不够必须把仓库源也换成国内镜像整个流程才算真正打通。3. 镜像源实操让 Alas 本体和依赖都能跑起来3.1 先确认你的 Alas 目录用的是哪种更新方式开始动手之前先打开 Alas 所在目录看一眼有没有.git文件夹。用命令行的话cd 你的Alas目录 ls -a如果是 Linux 或 Windows 的终端ls -a会显示隐藏文件里面有.git就说明之前是用 git 方式部署的可以直接用 git pull 更新。如果看不到.git说明当初是下载 zip 解压部署的那你得走压缩包覆盖更新的路线或者这次干脆改成 git 方式重新部署。两条路线我都用过。git 路线的最大优势是能够保留本地全部历史记录更新时只拉取增量省流量也快zip 覆盖路线胜在干净但如果操作不当很容易把你自己的配置文件覆盖掉后面我会专门讲这个坑。确认方式是第一步别跳过。3.2 git pull 配加速前缀的操作步骤如果你确认是 git 部署可以先在原始 remote 地址正常执行一次 pull看看实际速度。如果卡住就改用带加速前缀的地址cd 你的Alas目录 git pull https://ghfast.top/https://github.com/LmeSzinc/AzurLaneAutoScript.git master这类 GitHub 加速服务的工作方式其实很直接你提供一个 GitHub 的原始 URL加速服务在国内服务器上帮你把内容取回来再转给你。所以 URL 的拼写规则往往是“加速域名 原 GitHub 完整地址”。用加速前缀拉取时注意两个细节不要用强制 force pull除非你非常清楚自己在干什么。正常更新用默认策略即可强制拉取会把本地改动直接覆盖掉。拉完之后检查一下 remote 地址有没有被改动。加速前缀只是临时通道下次更新建议切回官方地址否则哪天加速服务失效了你自己还以为官方仓库挂了。检查 remote 地址的方法git remote -v如果确定临时用的加速地址被写进了配置用下面的命令改回来git remote set-url origin https://github.com/LmeSzinc/AzurLaneAutoScript.git3.3 release 压缩包的加速下载与覆盖如果你没有.git目录或者不想折腾 git直接下载最新 release 压缩包也行。完整步骤打开官方 GitHub 仓库的 Release 页面找到最新版本对应的 Source code 下载链接一般是 zip 格式地址类似https://github.com/仓库名/archive/refs/tags/版本号.zip或者refs/heads/master.zip。复制这个原始 URL拼上加速前缀。常见格式是curl -L -o alas_new.zip https://ghfast.top/https://github.com/LmeSzinc/AzurLaneAutoScript/archive/refs/heads/master.zip下载完成后解压到一个临时目录再把临时目录里的内容覆盖到你原来的 Alas 目录中。这里最关键的一点是覆盖而不是删除原目录再解压。原目录里除了脚本文件还有你的配置文件删了就等于清空所有设置。正确做法是把解压出来的文件复制进去提示是否覆盖时选“全部覆盖”但跳过 config 相关目录。3.4 配置清华 PyPI 镜像和 conda 镜像脚本本体下来之后紧接着就是装依赖。无论你是直接用系统 Python 还是用 conda都建议先把源切到国内镜像。pip 用户一条命令搞定pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple以后所有 pip 安装都会默认走清华源。如果你只想在这一次安装时临时用镜像可以这样python -m pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simpleconda 用户则需要修改 .condarc 配置文件。打开用户主目录下的.condarc写入以下内容channels: - defaults show_channel_urls: true default_channels: - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/msys2 custom_channels: conda-forge: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud改完之后执行一次conda clean -i清掉旧的索引缓存否则 conda 可能拿着旧缓存继续访问境外源。3.5 装依赖时最容易搞混的环境问题这一节单独拎出来说是因为我见过太多人倒在依赖安装这一步。Alas 经常运行在独立 Python 环境里如果你在终端直接敲pip install很可能用的是系统全局的 pip而不是 Alas 所在虚拟环境的 pip。建议按这个顺序操作# 先列出当前 conda 环境 conda env list # 激活 Alas 对应的环境 conda activate 你的环境名 # 确认 python 和 pip 指向同一环境 which python which pip确认无误后再安装依赖python -m pip install -r requirements.txt注意这里我推荐python -m pip而不是直接pip。原因很简单当环境里存在多个 Python 版本或虚拟环境时pip这个命令可能关联到别的解释器而python -m pip保证用的是你当前激活的 python 对应的 pip。这个细节能避免很多“明明装过了却还是报 ModuleNotFoundError”的怪问题。4. 更新时最容易翻车的点配置迁移与本地改动4.1 为什么不能直接删旧目录再重新下载我经常看到群里有人问更新这么卡那我直接把旧的删了重新下载一份最新版行不行技术上不是不行但代价很大。Alas 的配置文件和运行数据通常在项目目录内部包括你的部署设置、出击队列、账号相关配置、各种自定义开关。这些都不是只存在于一个 conf 文件里那么简单有些配置分散在多个文件中互相引用。你删掉整个目录等于把这些全清空然后面对一份全新未配置的脚本重新设置一遍的功夫足够你远程更新几个来回了。另外Alas 的依赖是部署在 Python 环境里的目录删了之后你还要重新跑一遍部署脚本等于把整个安装流程重走一遍。所以我给的建议是永远保留原目录用覆盖或 git pull 的方式更新而不是删了重来。4.2 新版本的迁移脚本会改动你的配置更新之后第一次启动时你可能看到类似 migrating / 迁移配置的提示或者发现某些配置文件出现了.bak后缀的备份文件。这是正常现象说明新版本改了配置文件格式迁移脚本正在把旧配置转换成新格式。迁移过程中有什么要注意的首先是别中途强制关闭进程。迁移脚本通常是一步步读写文件的中途断电或强杀进程可能导致配置文件写到一半留下一个残缺状态。其次是迁移完成后建议到 GUI 设置页里把每个分组点开扫一眼确认关键开关的值没被重置成默认值。Alas 的大版本更新常常会新增设置项新增项的默认值未必符合你的使用习惯。如果你的配置比较复杂又恰好跨了大版本更新迁移后备一份迁移日志看看有没有警告。实在遇到迁移后 GUI 报错把报错信息里的关键字拿去 GitHub Issues 搜一下大概率不是个例。4.3 备份的正确姿势与恢复方法说起来讽刺很多人只有把配置弄坏了才意识到备份有多重要。这里给出一个标准操作建议每次更新前都执行一次cd 你的Alas目录 cp -r config config_backup_$(date %Y%m%d%H%M)如果你用的 shell 不支持这个命令格式在 Windows 上可以直接把 config 文件夹复制一份改个带时间的名字。这一步的成本很低但能让你在迁移出错时两分钟内回滚。万一迁移脚本真把配置弄坏了恢复的做法是先把当前 config 目录改名留底再把备份目录复制回 config 的位置mv config config_broken_$(date %Y%m%d%H%M) cp -r config_backup_202501011200 config然后重新启动 Alas确认配置恢复。注意恢复之后版本号还是新版如果新版要求的配置格式和旧备份不一致你可能会在启动时看到格式转换提示此时让脚本再迁移一次即可一般不会二次损坏。5. 更新后的验证清单和镜像源使用原则5.1 我每次更新后必做的四项验证更新完并不代表结束我习惯按下面这个顺序快速验证一遍能省去后面很多排查时间检查启动日志Alas 启动时会输出日志重点看有没有 Error 或红色报错。如果一切正常日志会进入正常的调度循环。核对版本号git 部署的话用git describe --tags --always看当前版本GUI 里通常也有版本显示两者对得上就说明更新到位了。跑一次测试在 GUI 里执行一次截图模拟或测试识别确认识别框能正常框选目标。这一步能排除老配置跟新识别逻辑不兼容的情况。复查设置项把设置页每个分组的几个关键项看一遍特别是有没有新增的或变成默认值的项。这四项做下来基本就不会出现“更新完看似成功挂机一小时才发现识别全乱”的情况。5.2 别在所谓“官网”下载魔改版搜索 Alas 相关关键词时你会看到不少标着“alas 碧蓝航线官网”“alas 脚本下载”的站点有些排得还挺靠前。这里必须给新手提个醒镜像源可以加速 GitHub 的下载链路但你可不要图省事去下载第三方站点打包好的“一键版”。Alas 的官方渠道就是 GitHub 仓库以及由仓库维护者发布的文档站。第三方打包的安装包你无法验证里面有没有被塞进额外代码跑起来有多稳都是别人的说法风险不值得冒。镜像源的定位很明确它是帮你从官方仓库快速拿东西的工具而不是让你获取“另一个版本”的渠道。凡是看到“魔改版”“特别版”“极速版”这类字眼的直接绕开。5.3 镜像源选型的几个原则最后聊一下怎么选镜像源因为并不是所有镜像都同样可靠优先选择高校或大厂维护的镜像站清华 TUNA、中科大 USTC、阿里云的镜像都做了很多年稳定性有保障适合作为 pip/conda 的常规源。GitHub 加速前缀属于第三方服务和正规镜像站不是一个体量今天能用不代表明天还能用。所以不要只记一个至少保留两三个备选前缀卡住就换下一个。加速前缀只临时用于下载不要把它写进 git 的远程仓库地址长期使用。我之前也踩过这个坑图一时方便把 remote 改成加速地址结果加速服务维护导致我一度以为官方仓库宕机了实际上是我自己把通道写死了。镜像源用来解决问题别把工具本身变成新的隐患这是我这几年操作下来最深的体会。最后顺手分享一个个人习惯每次更新完我都会把 GUI 里显示的版本号记在备忘录里跟官方 Release 页面对一下。下次更新后如果版本号对不上说明更新或迁移可能出了问题能在早期就发现。如果你用的是 git 部署干脆把版本号核对做成习惯性动作花不了一分钟但能省下很多“以为更新成功、实际跑的还是旧代码”的排查时间。镜像源这件事说到底不难难的是把整个更新链路想明白别在错误环节反复重试。