脚本把同一个文件下了两遍
顺着这条报错去看安装脚本，机制并不复杂，反直觉的恰恰在这一步。脚本先用 curl 把 Claude Code 的可执行体下到本机的 binary_path，然后执行 "$binary_path" install。坑藏在这个 install 子命令里：它会把刚下过的整包再下一遍。也就是说一次安装，网络要完整地传同一个文件 2 遍。
这段机制有据可查。经本地复核 anthropics/claude-code 的 issue #106436：报障人 2026-10-31 18:02 提交，正文标注 Claude Code 版本 v2.1.314，截至 2026-11-01 状态仍 open。他复现用的是一条 120KB/s 的 DSL 慢线------第一遍下完，第二遍整包撞上脚本内置的 hard deadline，安装当场失败。按这条带宽算，同一个可执行体完整传 2 遍，下载时间直接 ×2；而脚本的 total deadline 是按「快速」网络设定的，慢线上第二遍根本到不了终点，超时是必然而非偶然。
这条 bug 的来龙去脉能凑齐 3 个 issue 印证同一根因。据 @mkbrewer 在 #89262 的评论（2026-10-31 22:47），它连更新都会触发，不止首次安装；再往前，同类的「安装超时」#88834 已于 2026-10-15 10:20 被以「另开 issue」关掉。三个 issue、横跨 16 天，指向的始终是同一个设计：第二次整包下载。
所以慢线上的失败，跟你带宽「够不够快」其实没关系，根因是脚本的第二次下载 套了一个总时长上限（total deadline），慢线就是够不到。多数人的第一反应是「再点一次 --force」，--force 跳过的是前置检查，改不了这个 deadline，点了也是白点。真正的分界线在这里：分清楚它到底卡在哪一次下载，比反复 --force 有用得多。下面 2 种走法，一张表看清楚：
| 走法 | 命令 | 网络风险压在哪 | 失败时你能做什么 | |
|---|---|---|---|---|
| 一把梭 | `curl install.sh | bash` | 100% 压进脚本内部的 hard deadline，你看不到也改不了 | 只剩 --force，它改的是前置检查，不改超时 |
| 两步走 | 先落地脚本读一遍，再手动拉可执行体 | 风险在你手里，可控、可续传、可换源 | 断点续传、换代理、换内网镜像 3 选 1 |
两条路各自的代价
「一把梭」的代价，是把全部网络不确定性都交给脚本里的 hard deadline。慢线必挂，而且 | bash 直接执行一份没人读过的外部脚本，很多内网的安全评审，这一步就过不去。它换来的只有省事：一条命令，不用知道它内部在干嘛。
「两步走」的代价，是多花 2 分钟：先把 install.sh 落地读一遍（它到底下哪、下到哪、再执行什么），可执行体也得你自己拉进来、放对位置。换来的是可控------网络一出问题，你手里有得换。核心就一句：把「第二次整包下载」这件事，从脚本手里交回你自己手里。
我们给一线项目做内网 AI 工具链部署，默认就走这套两步可控装法，实测下来慢线和代理环境反复用，再没被 hard deadline 卡住过。
两步可控装法内部就这么落：先 curl -O install.sh 落地读一遍；再手动拉可执行体，按网络 3 选 1------慢线加 -C - 断点续传、公司代理设 HTTPS_PROXY、纯内网走镜像源；最后本地执行 install。动作名字不重要，关键是让第二遍下载落在你续传/代理/镜像的控制下，而不是落在一个你改不动的 deadline 里。
绕过动作对号入座，一张表看清各自适用的 3 种网络情形，也能看清每招的边界在哪：
| 网络情形 | 绕过动作 | 说明与边界 |
|---|---|---|
| 公司代理 | 设 HTTPS_PROXY / HTTP_PROXY 再跑 |
只改「方向」，不改带宽------代理后面接的仍是慢线，第二次整包照样要续传兜底 |
| 慢线 / 丢包 | curl -C - 或 wget -c 断点续传 |
绕过 hard deadline 的关键一招：下断了接着下，不重头 |
| 完全内网 | 有网机器下好离线包，拷进内网再装 | air-gapped 时前两条都不适用，只能离线装 |
边界得说清楚，免得照搬翻车。这套两步走只在「网络通但慢」的前提下成立 ：完全断网的 air-gapped 环境，代理和续传都白搭，得走离线安装包；代理改的是方向、改不了带宽，所以代理出口后面接的慢线，第二遍下载仍要 -C - 兜住；--force 碰不到 hard deadline 本身，救不了第二次超时。这三条是我们踩过的坑，也是这套方法能用的边界------少一条，它就会在那个边界上翻车。
先选哪条路
怎么选，看你现在在哪种网。4 种情形对号入座，别跨情形套方法：
- 能出公网、带宽也够------一把梭其实可以，但先把 install.sh 落地读一遍再执行，安全评审和排障都省事。
- 慢线、丢包------两步走 + 断点续传，把第二次整包下载的风险交给
-C -兜住。 - 走公司代理出口------两步走 + 代理变量，方向对了再谈带宽。
- 完全内网、断网------前两条都不适用，直接离线包，有网机器下好再拷进来装。
我的判断是：内网或慢线部署 AI CLI 工具，「一把梭 | bash」是错的第一步。它把你本来能控制的风险，全押给了脚本里一个你改不动的 hard deadline。反过来，先分两步、可续传、可代理，多花 2 分钟，省的是整晚对着 timeout 干等。
我不同意把这条命令翻车归给「网络太慢」------网络慢只是放大器，真正的设计问题是第二次下载自带你改不动的 deadline，这个设计在慢线场景下一定会翻车。区别就在这：归给网络，你只能等它变快；归给脚本行为，你才有 3 种绕过招可换。
更关键的是这件事的长期成本。装一遍卡住是小事，卡住之后 4 种网络情形下团队各自乱试------有人加 --force、有人换 wget、有人直接手动下包、有人干脆放弃------没人沉淀出「第二次下载」这个根因，下一台机器、下一个同事还得从头踩一遍。把「双次下载 + 3 种绕过招」写进团队 SOP，前期 1 次 2 分钟，后面每 1 台机器都是 0 分钟卡等待。
归根到底，这一条命令翻车，翻的不是网络，是「没人读过它内部在干嘛」。留给你们一个两难：你们内网装 AI 工具，要么出公网一把梭，要么纯内网走离线包------这两条路在安全评审和运维成本上差得很远。你们现在卡在「出公网被卡带宽」还是「进不了内网」这一头？
今天就能做的四步（拿走贴进你们的部署 SOP）
- 先
curl -O install.sh落地读一遍，别直接| bash。 - 手动拉可执行体：慢线加
-C -，公司代理设HTTPS_PROXY，纯内网走镜像源。 - 本地执行 install，确认「第二次整包下载」这一步要么没有了、要么已落在续传里。
- 完全断网就预下 1 份离线包进内网再装；
--force救不了 hard deadline，别指望它。