半个月后我把记录翻了一遍，发现有些坑我踩了不止一次

8 月 11 日开始折腾，到 26 号基本稳住了。中间踩的坑我都单独写过，今天把它们翻了一遍，想看看有没有共同的毛病。

翻完发现有几个。

同一个报错，我每次都从零查起

NapCat 连不上 6195 这事，我遇到过三次：一次是适配器没启用（ECONNREFUSED），一次是容器不在同一张网里（EAI_AGAIN），一次是包太大（Max payload size exceeded）。

第三次遇到的时候，我还是先把前两次查过的东西又查了一遍。明明报错不一样，只要先看一眼报错本身就能判断该往哪儿查。

后来我强迫自己改了个习惯：报错出来，先问一句"这句话在说哪一层"，再去动那一层的东西。

后台 502 那次也是这个毛病。我看到"打不开"就去翻应用日志，其实日志里 Starting WebUI at 0.0.0.0:6185 已经说明服务是好的，问题在外面进来的路上。那晚两个多小时全花在错误的方向上。

中间有一阵子，机器人隔几天就出一次毛病，我的处理方式是重启。重启完能用，过两天又来。

有一次我真的烦了，说了一句：

我不要短时解决方案，我要的是 bot 以后稳定不出这个错误。

从那之后我才开始认真找根因。找完发现前面那些"重启就好"的问题，根因都很具体：

不停连不上的，是适配器开关和容器网络；文件发不出去的，是两个容器路径对不上；配置不生效的，是那个键根本没被读。每一个都能一次修好，不用天天重启。

这条我犯了三次，每次代价都不小。

写了个 "db" 配置块，程序回我一句 Config key removed: db，直接删了；JSON 文件开头有三个字节的 BOM，我盯着看半天看不出来，解析直接失败；apt 走着一个已经死掉的代理，我还以为是镜像站抽风。

三次都不是"我写得不对"，而是"我改的地方不是它读的地方"。

现在我的顺序变了：改完先确认改动被读到了，再看结果。看日志有没有加载、看端口有没有真监听，几十秒的事。

在容器里敲宿主机的命令——进容器之后我输过 docker、pip、ps、nano，全都不存在。进之前先想一下"我现在在谁的身体里"就能避免。

改插件源码不留备份——改过 main.py 跳过渲染，下次插件升级被整个覆盖，改的东西全丢。

把"卸载插件"当"重装"用——Galgame 那次，卸载重装了三遍都是同一个报错，因为配置还留在数据库里，重装读的还是那条坏配置。

也有到现在没修好的：让模型稳定返回 JSON 的那个功能，Pixiv 的回退图源，还有一个小众插件的图片上传（它其实返回的是 401，是我自己开 F12 抓请求才发现的）。

我现在能接受了。知道哪些能修、哪些该换个方案、哪些直接放弃，这件事本身比修好它们更省时间。