v8.0.52 起 go install 装不上：卡在 go.mod 第 44 行，修复补丁十一分钟就关了
CLIProxyAPI 从 v8.0.52 起按版本安装全部失败，卡在 go.mod 第 44 行那行 replace；这篇把四种装法逐条对过，给出今晚能用的替代路径，以及那条开了十一分钟就被关掉的补丁。
北京时间 11 月 3 日 03:55 到 06:32 这两个半小时，中转这边只有一件事需要今晚动手。
CLIProxyAPI 从 v8.0.52 起，所有「按版本取模块再编译」的装法全部失败。
go install …/cmd/server@v8.0.52 与 go run …@latest 都在取到模块那一步退出，进程根本没被编出来1。断的只有这一条路。发行页的二进制包、项目自己推的 Docker 镜像、把仓库克隆下来自己 build，三条都照常跑。
修复补丁只活了十一分钟：06:11 提出，06:22 由报障人本人关掉，没有合并。到现在 tag、main、dev 三处的 go.mod 第 44 行都还带着那一行。
先对一遍你的装法中不中招
先按你现在怎么装对一遍，再决定要不要往下读。
| 你的装法 | 现在还能不能用 | 依据 |
|---|---|---|
go install …@v8.0.52、go run …@latest | 不能，取模块时直接报错退出 | 报错原文见下一节1 |
go install …@v8.0.51 | 能 | v8.0.51 的 go.mod 里没有 replace2 |
发行页的 CLIProxyAPI_*_linux_*.tar.gz | 能 | 二进制由发版流水线在仓库上下文里编出，不走模块代理3 |
docker pull eceasy/cli-proxy-api:v8.0.52 | 能 | 镜像在切 tag 时构建，03:17 已经推好4 |
克隆仓库后 go build ./cmd/server | 能 | 你是主模块，replace 照常生效5 |
只跑二进制或镜像的话，这期可以直接跳到最后一节。
报错长什么样
06:05 开出的报障单写得很干净：
Since 6e6afab，一条启动命令，一段报错。go: github.com/router-for-me/CLIProxyAPI/v8/cmd/server@v8.0.52 (in github.com/router-for-me/CLIProxyAPI/v8@v8.0.52): The go.mod file for the module providing named packages contains one or more replace directives. It must not contain directives that would cause it to be interpreted differently than if it were the main module.
作者还写了一句
I would expect it to work, which it did until v8.0.51——同一条命令、同一台机器，上一版之前一直是通的1。自查只看一处：日志里有
must not contain directives，就是这一条，跟你跑什么协议、用哪个模型无关。单子写明
Affects all platforms，与操作系统无关；它也不是运行期故障，是编译都没开始。
Since 6e6afab、那条 go run …@latest 命令、报错原文三行，以及底部作者自己关成 completed、全程零评论的记录1一行 replace 为什么能打掉按版本安装
被取到的模块里如果带 replace，Go 认为它会被「按另一种方式解释」，于是直接拒收。没有客户端开关能绕过，这项检查发生在读完它 go.mod 的那一刻。
那这一行为什么要写进去？v8.0.52 把 gjson、sjson、base64 三个解析库整体换成了 moego 的镜像实现7。
上游 MoeForge/moego 只到 v0.1.0-alpha.1；项目自己维护的 router-for-me/moego 到 v0.1.1，多出来的正是 arm64 的 NEON 加速。
可 fork 的 go.mod 第一行仍写着
module github.com/MoeForge/moego，所以不能直接把 import 路径改成 router-for-me8。能把两者接上的唯一写法就是 replace；而 v8.0.52 这个 tag 恰好就打在那笔迁移提交上9。
所以「按版本取到的模块里带 replace」不是手滑，是这个取舍的必然结果。
修复单只开了十一分钟
PR #7216 的内容很小，三处10。
一是删掉 go.mod 里那行 replace；二是给 go.sum 补上
github.com/MoeForge/moego v0.1.0-alpha.1 的校验行；三是给 pr-test-build.yml 加一条守卫，go mod edit -json 出来的 Replace 或 Exclude 不为空就让流水线失败。代价 PR 里也写了：删掉 replace 之后 arm64 回落到上游那一版，失去 NEON 加速。
关闭方式是作者本人关的，
merged 为 false，没有任何维护者回应。22:22:47 先关报障单，九秒后关补丁，两下都是他自己点的。于是三处原样：
refs/tags/v8.0.52、main、dev 的 go.mod 第 44 行都在。v8.0.52 的发版流水线里也没有那条守卫——它只存在于被关掉的那张补丁里11。
一句话：今晚不会有一个新版本自动把它修好，得等下一个人提、下一个人合、再出下一个 tag。
今晚能怎么装
四条路，按省事程度排。
这是项目自己的流水线在切 tag 时构建的镜像，amd64 与 arm64 各一份、再合成多架构 manifest12。代价是你得走容器；已经在用镜像的，只是把 tag 从
latest 钉到版本号。用发行页的二进制包。 Linux 有两种：
CLIProxyAPI_<version>_linux_<arch>.tar.gz 是默认包，GLIBC 2.17 基线、支持动态库插件；_no-plugin 那个给 musl 或老系统，不支持插件。FreeBSD 只有 aarch64_no-plugin 一个包3。代价是没有 Go 工具链就改不了代码；要自己打补丁得回到第三条。
克隆仓库自己 build。
git clone --depth 1 --branch v8.0.52 https://github.com/router-for-me/CLIProxyAPI
cd CLIProxyAPI && go build -o CLIProxyAPI ./cmd/server这条路一下就通，因为你是主模块，replace 照常生效。Dockerfile 自己就是最好的证明：
COPY . . 之后 go build 跑在仓库上下文里。
COPY go.mod go.sum 之后 go mod download、再 COPY . . 与 go build，全程是仓库上下文，所以镜像不受那行 replace 影响5代价是本地或 CI 要有 Go 1.26——go.mod 里钉的是 1.26.10。
钉住老版本，或者自己打那两行。
@v8.0.51 没有 replace，按版本安装还能用2。自己打就是 PR 里那两处：删第 44 行，再
go mod tidy 补回校验行10。代价两条：arm64 失去 NEON 加速；每升一版都要重打，因为改的是别人仓库里的文件。没有第五条。
-mod 与 GOFLAGS 都作用不到这一层，这项检查在取到模块、读它 go.mod 时就做完了。上一期那句话要补个边界
今天 03:00 那期把 v8.0.52 写成了普通的可用升级，还写了「dev 与 tag 同提交」。两句都要收窄。
本期实测：tag 与 main 都停在 6e6afab，dev 已经在 e5827065。多出来那笔是 03:47 落下的 #7183——凭证被禁用、刷新 token 又被拒时，自动续期会原地打转13。
这笔的时间早于上期发稿的 03:55，所以不算本期新增；只是「同提交」那句在当时就已经不成立。
另一句要按装法分：二进制与镜像可用，按版本安装不可用。同一个版本号，两种结论。
同一窗口的其余动静
Claude 侧有个更贵的隐患。 Fable 单独吃一条 429，会把整条凭证冷却约六天，同号的 Opus 一起被挡。
04:01 有第三方用合成上游复现了它：同样的响应头形状下，
claude-fable-5-1 的一条 429 把凭证级配额设成约 6.3 天；换成显式的健康 5 小时证据，同一个 429 就只落在模型上14。现成开关是
upstream.claude.model-level-cooling，默认 false15。已经被冷却的凭证，用管理端
POST /v8/management/routing/cooldown/reset 清一次；带 401 失败记录的凭证这条清不干净，这点上一期核过。四仓这一格没有新版本。
| 仓库 | 当前版本 | 窗口内动作 |
|---|---|---|
| CLIProxyAPI | v8.0.52（11-03 03:15） | 无新 tag；#7215 与 #7216 一开一关16 |
| sub2api | v0.2.19（10-23 15:44） | 无新 tag，窗口内 0 条新单17 |
| codex-proxy | 预发布 v2.1.22-beta.7ae8044（11-02 20:07） | 无新 tag，窗口内 0 条新单18 |
| codex2api | v3.1.2（10-28 04:34） | 无新 tag，窗口内 0 条新单19 |
Codex 额度这边今天 UTC 还没有重置，最近一次已验证的全局重置是 10-28 14:35，累计 61 次、10 张 banked，节奏仍写着约每两天一次23。
社区两侧没有硬信号。 两个大板块的最新 25 条里，落在窗口内的只有额度抱怨与作品展示，没有可核对的技术细节；OpenAI 开发者社区 Codex 分区最新一条是 05:44 的 Multiroot Workspaces，与中转无关。
今晚就能做的三件
一，搜一遍启动脚本与 CI：还有没有
go run …@latest、go install …@<version>。有就换成镜像、二进制或 @v8.0.51。二，把镜像与二进制钉到版本标签，别用
latest。今天这一版镜像推得没问题，但版本号是唯一能让你下一次知道「这台跑的是哪一版」的东西。三，Claude 侧把
upstream.claude.model-level-cooling 打开；已经被冷却的凭证在管理端清一次，别等六天。References
- 1
- 2CLIProxyAPI go.mod at v8.0.51\
github.com
- 3CLIProxyAPI release workflow at v8.0.52\
github.com
- 4eceasy cli-proxy-api tags on Docker Hub\
hub.docker.com
- 5CLIProxyAPI Dockerfile at v8.0.52\
github.com
- 6
- 7
- 8router-for-me moego go.mod at v0.1.1
github.com
- 9CLIProxyAPI go.mod at v8.0.52
github.com
- 10
- 11
- 12
- 13Issue 7183
github.com
- 14
- 15
- 16CLIProxyAPI v8.0.52 release\
github.com
- 17sub2api v0.2.19 release\
github.com
- 18
- 19codex2api v3.1.2 release\
github.com
- 20OpenAI status
status.openai.com
- 21Anthropic status
status.anthropic.com
- 22Google Cloud status
status.cloud.google.com
- 23Codex Reset 追踪站
codex-reset.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.