162、【Agent】【OpenCode】TuiThreadCmd（fetch 工厂函数）

【声明】本博客所有内容均为个人业余时间创作所述技术案例均来自公开开源项目如GithubApache基金会不涉及任何企业机密或未公开技术如有侵权请联系删除标题162、【Agent】【OpenCode】TuiThreadCmdfetch 工厂函数背景上篇 blog【Agent】【OpenCode】TuiThreadCmd联合类型分析了constmyFetch:typeoffetchasync(input,init?){...}// ^^^^^^^^^^^^^^^^ 类型描述用 // ^^^^^^^^^^^^^^^^^^^^ 实际实现也用 在语法上没问题因为这行代码被号清晰地劈成了两个完全独立的世界左边typeof fetch是类型注解只告诉编译器这个变量应该长什么样编译后直接消失右边async (...) {...}是箭头函数表达式是一个真实的 JS 值被赋值给了myFetch接着提到了这里并没有在类型定义里写实现只是在声明变量的同时给它标注了类型并赋予了初始值这三件事在同一行完成但彼此互不干扰接着分析了联合类型中的核心机制类型收窄当拿到一个联合类型的参数时TS 确实会禁止直接调用它们各自独有的方法但只要做一个判断TS 就会自动帮把类型收窄到确定的那一个接着分析了常见的收窄方式下面继续分析OpenCode下面继续分析这里的typeof fetch以及后面的内容typeof fetch后面的花括号{ ... }是createWorkerFetch这个工厂函数的实现体。而这个函数执行后返回的是一个符合typeof fetch声明的新函数。下面来详细分析// createWorkerFetch 是一个“工厂函数”它接收 client返回一个“假 fetch”functioncreateWorkerFetch(client:RpcClient):typeoffetch{// 注意这里返回的是一个【匿名异步箭头函数】returnasync(input:RequestInfo|URL,init?:RequestInit):PromiseResponse{// 1. 把输入标准化为 Request 对象constrequestnewRequest(input,init)// 2. 读取 body因为 RPC 不能传 Streamconstbodyrequest.body?awaitrequest.text():undefined// 3. 通过 RPC 发给 Worker 执行真正的网络请求constresultawaitclient.call(fetch,{url:request.url,method:request.method,headers:Object.fromEntries(request.headers.entries()),body,})// 4. 用 Worker 返回的数据重建 Response 并返回returnnewResponse(result.body,{status:result.status,headers:result.headers,})}}核心要点拆解返回值是一个函数return async (...) { ... }说明createWorkerFetch返回的不是数据而是一个可执行的异步函数。签名严格匹配返回的这个匿名函数参数是(input, init?)返回值是PromiseResponse与原生fetch的声明逐字对应所以才能通过typeof fetch的类型检查。闭包捕获client返回的函数内部使用了外部的client变量这是典型的闭包用法。每次调用createWorkerFetch(rpcClient)都会生成一个绑定了特定 RPC 通道的专属fetch函数。一句话总结createWorkerFetch是一个生产fetch的工厂给它一个 RPC client就能吐出一个“假 fetch”。这个假 fetch的壳子类型签名和真 fetch 一模一样但内核函数实现已经被替换成了 RPC 转发逻辑这里有人可能会有疑问为什么要这么用代理直接用原生 fetch 不行吗直接用原生 fetch 当然能跑但在 Worker / RPC / 微服务 这种特定架构下直接用原生 fetch 会导致如下三个致命问题。createWorkerFetch的存在就是为了解决这些问题1. 网络边界与权限隔离最核心原因在 Worker、Service Worker 或 Serverless 环境中代码运行在沙箱里根本没有直接访问外网的权限。原生 fetch尝试直接发起 HTTP 请求 → 被沙箱拦截 / 报 Network Error。代理 fetch把请求参数序列化通过 RPC 通道发给有网络权限的宿主进程Host/Main Thread由宿主代为请求再把结果传回来。本质这不是替换fetch而是把网络请求变成了跨进程/跨线程的消息传递。2. 统一管控与可观测性如果业务代码到处散落着原生 fetch则根本无法集中管理比如鉴权注入每个请求都要手动加 Token代理 fetch 可以在内部自动注入。日志/监控想统计所有请求的耗时、成功率代理 fetch 内置埋点业务代码零侵入。Mock/测试单元测试时不想真发请求换一个返回假数据的代理 fetch 即可不用改任何业务代码。重试/熔断网络抖动自动重试在代理层统一实现避免每个调用方重复造轮子。3. 类型安全 零改造成本这就是前面讨论typeof fetch的意义所在如果不封装成typeof fetch就得定义一套自己的rpcFetch(url, options)API所有现有代码都要重写。封装成typeof fetch后任何接受标准 fetch 的第三方库如 axios、swr、react-query都能无缝接入一行代码都不用改。什么时候不需要代理如果只是在普通浏览器页面或普通 Node.js 脚本里发请求没有任何沙箱限制、不需要统一管控那直接用原生 fetch 完全没问题没必要过度设计。一句话总结原生fetch是自己亲自去拿快递createWorkerFetch是把取件码发给有门禁卡的同事让他帮拿回来。当代码没有出门权限或者需要统一管理取件流程时就应该用代理fetch。OK本篇先到这里如有疑问欢迎评论区留言讨论祝各位功力大涨技术更上一层楼更多内容见下篇 blog