3.7 KiB
3.7 KiB
换协议端那天：文件发送整体故障，以及"我把它弄哑了"
发现时间：2026-09-14 20:39（晚间快照时段） 当前状态：✅ 已修复（20:47 验证通过） 影响任务：主人的文件发送、以及一位朋友的期货回测交付（20:04~20:46 连续十三次失败）
一、现象
主人问「你怎么不能发出文件了」。复现后报错非常干脆：
ENOENT: no such file or directory,
realpath '/AstrBot/data/workspaces/.../file_test.txt'
关键诊断动作：把对方自己上传给我的那份文件再发回去——同样 ENOENT。 那份文件百分百在磁盘上 → 所以不是路径写错，是"发文件"这个功能整体失效。
前后共试 13 次：3 个不同目录、2 种扩展名，全部失败。
二、根因（两层）
第一层：新协议端没有挂载 AstrBot 的数据目录
- AstrBot 递过去的是它自己容器内的路径（
/AstrBot/data/...）。 - 旧协议端当年特意挂载了 AstrBot 的数据目录，所以能"看见"这些文件。
- 这次迁移时我漏了这一条挂载 → 新协议端那边那个路径是空的 → 文件"不存在"。
第二层（真正的坑）：修它的方式，会把登录态弄掉
补挂载必须重建容器。而重建新协议端容器 = QQ 登录态丢失。
于是报错从 ENOENT 变成了：
aiocqhttp.exceptions.ApiNotAvailable
—— AstrBot 认为"这个 API 不可用"，因为承载 API 的那条通道已经断了（登录没了，节点未激活，反向连接没建立）。
三、为什么我绕了很久
我在错误的方向上排查了：端口监听、节点配置文件、容器网络、DNS 解析——全都对，就是不通。
最后是截了一张 QQ 桌面的图，才看见屏幕上明晃晃一个二维码。 → 掉登录了。
教训：当"配置全对但就是不通"时，先去确认最基础的那一层状态（登录态），而不是继续深挖配置。
四、处置步骤（可复用）
- 先复现，拿到确切报错；
- 交叉验证：用"对方上传的文件"回发，区分"路径错"与"功能坏"；
- 补挂载 AstrBot 数据目录到协议端容器（两个路径都要对齐，覆盖 AstrBot 容器内视角与宿主机视角两种写法）；
- ⚠️ 重建容器前必须先打招呼——QQ 会掉登录，需要重新扫码；
- 验证三件事：协议端容器内能
ls到文件 → 反向连接已建立 → 实际发一次； - 旁路兜底：故障期间改用"把脚本压成几十行的内联版本"让对方直接复制，不要让交付完全停摆。
五、沉淀（写进肌肉记忆）
- 🔴 重建新协议端容器 = 掉登录。以后改它的配置，先问一句"现在方便扫码吗"。
- 🔴 协议端的真实节点配置是那个带账号名的文件，不是默认的那份。第一遍我看了默认文件，白绕一圈。
- 🟡 文件发送依赖"协议端能看见 AstrBot 的数据目录"——这是一条隐式依赖，迁移协议端时必须逐条对照旧容器的挂载表，不能只看文档。
- 🟡 故障期间能立刻给的最小可用版本，比一句"我在修"值钱。
六、当晚顺带记录的两条同源经验
- 公网暴露的窗口只有二十秒：新协议端起来二十来秒，VNC 端口就被一个陌生外部地址摸到（密码验证失败挡住）。→ 立即收回本机回环，只放开需要的那一个入口。
- VNC 口令只有前 8 位有效（协议本身的 8 字节限制）。给 16 位强密码，实际生效的是前 8 位——这类"我以为是 A、实际是 B"的事，必须实测。