场景与痛点
2026 年 Deno 生态里，JSR（jsr: 前缀）与 npm 兼容路径常常并存：同一仓库既可能从 jsr.io 拉 scoped 包，也会命中企业代理后的 npm registry。远程 Mac 作为 CI 节点时，典型痛点是：元数据请求小而密、tarball 偶发大文件，跨境链路下更容易出现 TLS 握手慢、代理空闲断开、并发 Job 互相抢出口带宽。若再用全局默认 DENO_DIR承接所有流水线，还会放大缓存污染与锁文件漂移——表现为「本地能过、CI 偶发解析到不同子依赖」。
因此决策顺序建议固定为：先锁版本（deno.lock）→ 再隔离缓存（DENO_DIR）→ 最后调并行与超时。下表给出「该不该上 Deno/JSR」与「该把复杂度花在哪」的快速裁决。
| 你的约束 | 更合适的策略 | 远程 Mac 上的主要风险 |
|---|---|---|
| 以 JSR 官方包为主、要可复现构建 | Deno + deno.lock + 冻结安装 |
锁未提交或未冻结导致「隐式升级」 |
| 大量遗留 npm 依赖、短期无法改 spec | Deno npm 兼容层 + 明确 registry；逐步把核心库迁 jsr: |
双注册表下缓存键混用、代理规则不完整 |
| 共享机构出口、峰值并发高 | 每流水线独立 DENO_DIR + Job 级并发封顶 |
全员同时 deno cache 触发重试风暴 |
Deno/JSR 拉取路径对照表
把「解析从哪里发生、缓存落在哪一类键上」写清楚，是跨境排障的前置条件。jsr: 包由 JSR 提供元数据与制品；npm: 或兼容声明则走 npm registry（常经企业 Nexus/Artifactory）。两者在 HTTP 路径、缓存布局与失败重试特征上并不相同，不要假设「调一次镜像就万能」。
| 维度 | JSR（jsr:） |
npm 兼容路径 |
|---|---|---|
| 典型入口 | jsr.io 元数据 + 制品拉取 |
配置的 npm registry（含私服镜像） |
| 映射位置 | deno.json / import map 中显式前缀 |
deno.json 的 npm 相关字段或安装输出 |
| 私有认证 | DENO_AUTH_TOKENS（主机=令牌） |
同上或 registry 专用 token；勿写入仓库 |
| CI 可观测性 | 按主机拆分拉取日志；关注 401/403 与重定向链 | 关注 lock 与 registry 指纹是否一致 |
若流水线同时拉 Git 子模块与容器镜像，建议把「HTTP 出口策略」与 Deno 对齐：统一代理、统一证书、统一 NO_PROXY 列表，避免只有 npm 走内网而 jsr.io 仍绕外网。
lockfile 与缓存目录可执行参数
下列参数以「复制到 shell 或 CI 环境变量」为目标，优先保证可复现与多 Job 不互踩。Deno 侧核心缓存根由 DENO_DIR 控制；锁文件请入库并在 CI 使用冻结语义，避免远程构建偷偷升级传递依赖。
| 目标 | 变量 / 文件 | 建议写法（远程 Mac CI） |
|---|---|---|
| 缓存根隔离 | DENO_DIR |
$HOME/.cache/deno-ci-${CI_PIPELINE_ID:-local} |
| 锁文件 | deno.lock |
提交仓库；CI 使用 deno install --frozen（或当前版本等价冻结标志） |
| 企业证书 | DENO_TLS_CA_STORE / SSL_CERT_FILE |
system 或指向聚合 PEM；与代理场景一起验收 |
| 出网代理 | HTTPS_PROXY、NO_PROXY |
内网 registry 与 localhost 写入 NO_PROXY |
| 私有 registry | DENO_AUTH_TOKENS |
registry.company.com=xxxxx 由密钥管理注入 |
- P0：
deno.lock入库 + CI 冻结；否则一切并行调优都是沙上建塔。 - P1：每 Job 独立
DENO_DIR；缓存归档键包含锁哈希、Deno 次版本、registry 主机名。 - P2：再调
deno test --parallel与矩阵并发；共享机优先「少而稳」。
CI 并行与超时阈值
远程 Mac 上最常见的误判，是把「本机笔记本上跑得飞快的 deno cache」直接搬到三台 Runner 同时冷启动的共享环境。并行应分层：流水线之间（队列与 max-parallel）、单 Job 内（deno test --parallel）、进程内异步拉取（由运行时管理）。建议用下表作初值，再在监控上看出口带宽与磁盘 IO，而不是反向先拉满并发。
| 层级 | 旋钮 | 共享远程 Mac 起点 | 说明 |
|---|---|---|---|
| 编排 | 矩阵 max-parallel / 队列 |
1–2 | 冷缓存阶段尤其要限流，热缓存再放宽 |
| 测试 | deno test --parallel |
开，但配合上面限流 | CPU 饱和时收益递减，反而放大 flaky |
| 安装/缓存 Job | CI timeout-minutes |
15–30 | 跨境首次拉取常长于内网；可分「锁文件校验」与「全量 cache」两 Job |
| 整流水线 | 总超时 + 分步重试 | 按需 | 仅对 deno cache 步骤重试，避免重复跑测试浪费分钟数 |
与「构建池磁盘水位」相关的全局策略，可对照站内 企业构建资源池并发与磁盘 FAQ，把 DENO_DIR 纳入统一清理与水位告警。
跨境网络失败重试 FAQ
问：要不要一失败就删全局 Deno 缓存？优先删除当前流水线的 DENO_DIR 子目录，不要动其他团队的缓存根；若刚切换 registry 或代理，也必须换目录或清理后再全量 deno cache。
问：重试脚本怎么写才不吃爆队列？对 deno install / deno cache 外包三层循环：失败则 sleep 2、4、8 秒指数退避，仍失败再非零退出让编排层展示明确错误。
问：TLS 报错与证书链不完整怎么快速验证？先用 DENO_TLS_CA_STORE=system 与系统钥匙串对齐；企业中间证书缺失时，用聚合 PEM 通过 SSL_CERT_FILE 注入，并在同一 shell 复现 deno eval 最小拉取。
更泛化的 npm/Homebrew 重试与镜像切换，见 Git、Homebrew、npm 拉取稳定性 FAQ。
稳定拉依赖，再跑测试与发布
MacPull 提供 Apple Silicon 远程 Mac，适合与本地同构的 Deno 与原生工具链；定价、购买与帮助中心均可免登录浏览。全栈流水线还可对照 跨境 Git/npm/Homebrew 镜像优化 与 更多技术博客。