CodeCompanion.nvim 底层 HTTP 利器Plenary.Curl 库完整解析与实战指南【免费下载链接】codecompanion.nvim✨ AI Coding, Vim Style项目地址: https://gitcode.com/GitHub_Trending/co/codecompanion.nvim导读CodeCompanion.nvim 的绝大多数 HTTP 通信——从与 Anthropic、OpenAI、Ollama 等模型的请求往来到 GitHub Copilot 的 Token 换取与用量统计再到聊天中拉取远程图片——都建立在 Plenary.Curl 这一层薄薄的 curl 封装之上。本篇基于仓库中的 Plenary.Curl 源码.codecompanion/adapters/plenary_curl.md完整梳理其参数模型、返回结构、底层 curl 参数拼装逻辑与同步/异步两种调用方式并结合 http.lua、token.lua、stats.lua、get_models.lua 等真实调用点帮助读者彻底搞懂这条 HTTP 链路的每个环节进而在自己的 Neovim 插件或 CodeCompanion 自定义适配器中熟练使用 Plenary.Curl。一、Plenary.Curl 是什么Plenary.Curl 是 plenary.nvim 中内置的 curl 包装库作者为 github.com/tami5。它把裸curl命令行调用封装成一组表驱动的 Lua API开发者只需传入 Lua table 形式的参数库内部就会把它们翻译成 curl 的 argv 数组通过plenary.job异步执行并把响应解析回结构化的 Lua table。它天然带有三个特性这也正是 CodeCompanion.nvim 选择它的原因零额外依赖只要系统里有curl可执行文件即可工作同步/异步双模式既能阻塞等待返回完整响应也能以回调方式流式接收 stdout贴近 curl 语义几乎所有 curl 的常用能力认证、代理、表单、超时、HTTP 版本、忽略证书校验等都能通过简单参数透传。从源码结构看该库由四个部分组成对应 plenary_curl.md 中的分区util.*URL 编码、KV 表转换、临时转储路径生成等工具函数parse.*把用户参数逐项翻译成 curl 参数数组的解析函数parse.request/parse.response请求参数的统一拼装与响应解析模块末尾返回的get / post / put / head / patch / delete / request七个方法入口。二、核心 API统一参数模型与返回值Plenary.Curl 的设计哲学是「一个参数模型七个方法入口」。所有 curl 方法get、post、put、head、patch、delete、request都接受同一套参数 table返回同一个结构的响应 table。2.1 请求参数表源码开头的文档注释给出了完整参数定义参数类型说明urlstring要发起请求的 URLquerytableURL 查询参数会自动追加到 url 之后bodystring / filepath / table请求体。table 按 form 数据编码字符串若指向存在的文件则按文件内容发送authstring / arrayBasic 认证形如user:pass或{user, pass}formtable表单参数翻译为 curl 的-Frawarray任意额外的 curl 参数必须是数组/列表形式dry_runboolean为true时不真正执行直接返回要交给 curl 的 argv 数组outputfilepath下载目标路径翻译为-otimeoutnumber请求超时时间毫秒http_versionstringHTTP 版本HTTP/0.9、HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3proxystring代理格式[protocol://]host[:port]insecureboolean是否允许不安全连接忽略 TLS 证书校验此外从 request 函数 的实现中可以发现文档注释未列全的扩展参数method显式指定 HTTP 方法headers请求头 KV 表acceptAccept头内容翻译为-H Accept: ...compressed是否启用--compressed非 Windows 平台默认为truestream流式回调函数作为on_stdout使用callback请求完成后的回调提供回调时进入异步模式on_errorcurl 退出码非 0 时的错误回调dump响应头转储文件路径一般由内部自动生成。2.2 响应结构无论同步还是异步成功返回的响应都是如下结构的 table字段类型说明exitnumber底层 shell 进程的退出码statusnumberHTTP 响应状态码headersarrayHTTP 响应头字符串行数组bodystringHTTP 响应体源码中的 parse.response 展示了它如何从 curl-D转储的响应头文件中逐行提取状态码用模式^HTTP/%S*%s(%d)匹配HTTP/1.1 200 OK这类行把第一处匹配的200作为status其余非空行收进headersbody则由plenary.functional的F.join把所有 stdout 行拼成字符串。解析完成后会立即vim.loop.fs_unlink删除临时头文件。2.3 七个方法入口模块末尾plenary_curl.md#L339-L364通过partial闭包生成了七个方法return { get partial get, post partial post, put partial put, head partial head, patch partial patch, delete partial delete, request partial request, }partial的实现有两点值得注意既支持Curl.get(url, opts)也支持直接把url放进 opts 表、整体传参Curl.get({ url ..., ... })opts method request and opts or vim.tbl_extend(keep, opts, spec)除request外的所有方法会把method字段合并进参数表而request方法要求用户自行通过method参数指定或使用 opts 表时自动带上。三、参数如何变成 curl 命令底层拼装机制这是 Plenary.Curl 最核心、也最值得深读的部分。所有参数都会在 parse.request 中被逐项翻译成 curl 的 argv最终结果形如-sSL dump [--insecure] [--proxy ...] [--compressed] [-X METHOD] [-H K: V] ... [-d kv] [-F kv] [-d file] [-u user:pass] [--http2] [raw...] [-o out] url3.1 body 参数的三态分派body是灵活性最高的参数parse.request 开头 对它做了三种分派if type(b) table then opts.data b -- 1. table → 作为 -d keyvalue 表单数据 elseif silent_is_file() then opts.in_file b -- 2. 字符串且指向真实文件 → -d file文件内容 elseif type(b) string then opts.raw_body b -- 3. 普通字符串 → --data-raw 原样发送 end注意这里的silent_is_file使用pcall(P.is_file, ...)包裹即使传入的不是文件路径也不会抛错而是安全回退到原始字符串分支。CodeCompanion 正是利用「body 可以是指向文件的路径」这一特性把 JSON 请求体先写入临时文件再交给 curl见下文第四节。3.2 各 parse 函数的翻译规则源码中的解析函数逐一对应着 curl 参数参数/场景翻译结果对应函数headers表-H Header-Name: value下划线转连字符、首字母大写parse.headersaccept-H Accept: 值parse.accept_headerdata表-d keyvalue每个键值对一条parse.data_bodyraw_body字符串--data-raw 值parse.raw_bodyform表-F keyvalueparse.formquery表key1value1key2value2追加到 url 后用?连接parse.curl_queryparse.urlmethod非 head-X 大写方法名parse.methodmethod head-IHEAD 请求专用旗标parse.methodin_file-d 绝对路径parse.fileauth-u user:pass或-u user:passparse.authhttp_versionHTTP/2→--http2校验后小写并去掉/parse.http_versioninsecure--insecureparse.request内联proxy--proxy 值parse.request内联output-o 路径parse.request内联值得一提的细节基础参数固定为-sSLplenary_curl.md#L222即静默模式 跟随重定向 显示错误parse.http_version会校验取值传入未知版本直接error Unknown HTTP version.parse.url对 table 类型的 url 直接报错error Low level URL definition is not supported.低层 URL 定义不被支持parse.headers做规范化content_type→Content-Type即把下划线换成连字符并按词首大写处理。3.3 响应头转储与gen_dump_path为了拿到响应头Plenary.Curl 会让 curl 用-D把响应头写入临时文件util.gen_dump_pathplenary_curl.md#L77-L90。临时文件路径规则Windows%USERPROFILE%\AppData\Local\Temp\plenary_curl_id.headers其他平台$XDG_RUNTIME_DIR未设置则/tmp下的plenary_curl_id.headers。id由math.random生成的十六进制串填充避免并发请求互相覆盖。3.4 默认值合并正式发请求前plenary_curl.md#L283-L289会用vim.tbl_extend(force, {...}, specs)合并默认值local args, opts parse.request(vim.tbl_extend(force, { compressed package.config:sub(1, 1) ~ \\, -- 非 Windows 默认启用压缩 dry_run false, dump util.gen_dump_path(), }, specs))即默认启用--compressedWindows 除外、默认dry_run false、自动生成响应头转储文件。dry_run true时request直接返回 args 数组方便调试——这一特性对排查请求问题非常有用。四、同步与异步两种调用范式request 主体 基于plenary.job构建任务执行命令取自全局变量vim.g.plenary_curl_bin_path未设置时回退为curl——这意味着用户可以自定义 curl 二进制路径。4.1 异步模式推荐不阻塞 Neovim只要传了callback或stream就进入异步模式Curl.get(https://api.example.com/v1/models, { headers { Authorization Bearer .. token }, callback function(response) -- response.status / response.headers / response.body local ok, json pcall(vim.json.decode, response.body) end, })此时job:start()立即返回 job 对象Neovim 事件循环不被阻塞。若传入stream每次 stdout 输出都会回调CodeCompanion 的 SSE 流式响应正是借助这一机制实现的。curl 退出码非 0 时若提供了on_error则调用它否则直接error()错误信息包含方法、URL、退出码与 stderr 内容plenary_curl.md#L304-L317。4.2 同步模式不传回调时走同步路径job:sync(timeout)默认超时10000毫秒plenary_curl.md#L331返回解析后的响应 table。适合工具脚本、模型列表拉取等一次性调用场景。4.3 在 CodeCompanion 中的实践仓库对两种模式都有真实用例同步copilot/stats.lua 用Curl.get(https://api.github.com/copilot_internal/user, { sync true, ... })拉取 Copilot 用量统计随后vim.json.decode(response.body)解析额度快照异步回调adapters/utils/models/fetch.lua 用Curl.get(url, { callback vim.schedule_wrap(...) })异步拉取模型列表配合vim.wait实现「先异步发起、必要时阻塞等待」的混合策略流式http.lua 为流式请求设置request_opts[stream] self.methods.schedule_wrap(...)逐块接收 SSE 数据并写入响应日志文件。五、CodeCompanion.nvim 如何站在 Plenary.Curl 之上理解 Plenary.Curl 后再看 CodeCompanion 的 HTTP 层就一目了然了。5.1 统一 HTTP 客户端http.lualua/codecompanion/http.lua 是核心封装开头即local Curl require(plenary.curl)并通过静态方法表便于测试 mockClient.static.methods { post { default Curl.post }, get { default Curl.get }, ... }它做了几件 Plenary.Curl 本身不负责的事请求体写临时文件write_body_file用vim.fn.tempname() .. .json生成临时文件把编码后的 JSON body 写进去再以body body_file传给 Curl——正好命中 Plenary.Curl 的「body 是文件路径」分支请求头写文件write_headers_file把 headers 逐行写入--header file所需的文件附加 curl 原始参数build_curl_args注入--retry 3 --retry-delay 1 --keepalive-time 60 --connect-timeout 10流式时再加--tcp-nodelay --no-buffer并通过raw参数透传给 Plenary.Curl错误处理HTTP 状态码 ≥ 400 时把响应包装为{ message, stderr, status }错误。5.2 GitHub Copilot 适配器Copilot 相关的两处调用直观展示了 Plenary.Curl 的典型用法copilot/token.luaCurl.get(https://api.github.com/copilot_internal/v2/token, { headers { Authorization Bearer .. oauth }, on_error ... })换取 Copilot 会话 Token并设置_token_fetch_in_progress锁避免并发重复请求copilot/stats.lua携带Authorization、Accept: */*、User-Agent三个头同步获取用量数据。5.3 Ollama 模型列表ollama/get_models.lua 是异步嵌套的典型先Curl.get(url .. /api/tags, { callback ... })拉模型清单在回调里再对每个模型发起Curl.post(url .. /api/show, { body vim.json.encode({ model name }) })并维护pending表与_running标志来控制并发与完成判定。这正是「基于 Plenary.Curl 的回调式编程」的生动范例。5.4 远程图片下载utils/images.lua 展示了output参数的实际价值Curl.get(url, { output loc, callback ... })把图片直接下载到临时文件再从响应头中解析Content-Type得到 mimetype进而 base64 编码后发给多模态模型。六、实用技巧与注意事项结合源码实现总结几条实战经验调试用dry_run遇到请求异常时设dry_run true拿到完整 argv 数组可以直接在 shell 里复现local args Curl.post({ url https://..., body {...}, dry_run true }) print(vim.inspect(args))响应头在headers里是字符串行如需结构化取值可像 utils/images.lua 那样用line:match(^([^:]):%s*(.)$)自行解析键值。body传文件路径可避免大请求体占用内存CodeCompanion 的 JSON 请求体就采用写临时文件的方式这也是 Plenary.Curl 三态分派设计的初衷。流式响应务必包一层vim.schedule_wrap回调中直接操作 buffer/extmark 等 Neovim API 时应像 http.lua 那样调度回主循环避免在 job 的线程回调中触发 API 竞态。同步调用注意超时默认 10 秒超时对模型推理类请求可能不够务必显式传timeout毫秒。CodeCompanion 在 http.lua 的 send_sync 中默认给了 120000 毫秒。自定义 curl 路径通过vim.g.plenary_curl_bin_path可替换默认的curl二进制适合受限环境或需要特定版本的场景。七、小结Plenary.Curl 的价值在于用一张参数表统一了 curl 的近百个命令行旗标用plenary.job提供了不阻塞 Neovim 的异步能力再用统一的{ exit, status, headers, body }响应结构抹平了底层差异。CodeCompanion.nvim 的 HTTP 适配器体系、Copilot 令牌管理、Ollama 模型发现乃至图片拉取全部建立在这层薄薄的封装之上。掌握了本文的参数模型、翻译规则与同步/异步范式无论是排查 CodeCompanion 的网络问题还是在自己基于 plenary.nvim 的插件中发起 HTTP 请求都将事半功倍。【免费下载链接】codecompanion.nvim✨ AI Coding, Vim Style项目地址: https://gitcode.com/GitHub_Trending/co/codecompanion.nvim创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CodeCompanion.nvim 底层 HTTP 利器：Plenary.Curl 库完整解析与实战指南
CodeCompanion.nvim 底层 HTTP 利器Plenary.Curl 库完整解析与实战指南【免费下载链接】codecompanion.nvim✨ AI Coding, Vim Style项目地址: https://gitcode.com/GitHub_Trending/co/codecompanion.nvim导读CodeCompanion.nvim 的绝大多数 HTTP 通信——从与 Anthropic、OpenAI、Ollama 等模型的请求往来到 GitHub Copilot 的 Token 换取与用量统计再到聊天中拉取远程图片——都建立在 Plenary.Curl 这一层薄薄的 curl 封装之上。本篇基于仓库中的 Plenary.Curl 源码.codecompanion/adapters/plenary_curl.md完整梳理其参数模型、返回结构、底层 curl 参数拼装逻辑与同步/异步两种调用方式并结合 http.lua、token.lua、stats.lua、get_models.lua 等真实调用点帮助读者彻底搞懂这条 HTTP 链路的每个环节进而在自己的 Neovim 插件或 CodeCompanion 自定义适配器中熟练使用 Plenary.Curl。一、Plenary.Curl 是什么Plenary.Curl 是 plenary.nvim 中内置的 curl 包装库作者为 github.com/tami5。它把裸curl命令行调用封装成一组表驱动的 Lua API开发者只需传入 Lua table 形式的参数库内部就会把它们翻译成 curl 的 argv 数组通过plenary.job异步执行并把响应解析回结构化的 Lua table。它天然带有三个特性这也正是 CodeCompanion.nvim 选择它的原因零额外依赖只要系统里有curl可执行文件即可工作同步/异步双模式既能阻塞等待返回完整响应也能以回调方式流式接收 stdout贴近 curl 语义几乎所有 curl 的常用能力认证、代理、表单、超时、HTTP 版本、忽略证书校验等都能通过简单参数透传。从源码结构看该库由四个部分组成对应 plenary_curl.md 中的分区util.*URL 编码、KV 表转换、临时转储路径生成等工具函数parse.*把用户参数逐项翻译成 curl 参数数组的解析函数parse.request/parse.response请求参数的统一拼装与响应解析模块末尾返回的get / post / put / head / patch / delete / request七个方法入口。二、核心 API统一参数模型与返回值Plenary.Curl 的设计哲学是「一个参数模型七个方法入口」。所有 curl 方法get、post、put、head、patch、delete、request都接受同一套参数 table返回同一个结构的响应 table。2.1 请求参数表源码开头的文档注释给出了完整参数定义参数类型说明urlstring要发起请求的 URLquerytableURL 查询参数会自动追加到 url 之后bodystring / filepath / table请求体。table 按 form 数据编码字符串若指向存在的文件则按文件内容发送authstring / arrayBasic 认证形如user:pass或{user, pass}formtable表单参数翻译为 curl 的-Frawarray任意额外的 curl 参数必须是数组/列表形式dry_runboolean为true时不真正执行直接返回要交给 curl 的 argv 数组outputfilepath下载目标路径翻译为-otimeoutnumber请求超时时间毫秒http_versionstringHTTP 版本HTTP/0.9、HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3proxystring代理格式[protocol://]host[:port]insecureboolean是否允许不安全连接忽略 TLS 证书校验此外从 request 函数 的实现中可以发现文档注释未列全的扩展参数method显式指定 HTTP 方法headers请求头 KV 表acceptAccept头内容翻译为-H Accept: ...compressed是否启用--compressed非 Windows 平台默认为truestream流式回调函数作为on_stdout使用callback请求完成后的回调提供回调时进入异步模式on_errorcurl 退出码非 0 时的错误回调dump响应头转储文件路径一般由内部自动生成。2.2 响应结构无论同步还是异步成功返回的响应都是如下结构的 table字段类型说明exitnumber底层 shell 进程的退出码statusnumberHTTP 响应状态码headersarrayHTTP 响应头字符串行数组bodystringHTTP 响应体源码中的 parse.response 展示了它如何从 curl-D转储的响应头文件中逐行提取状态码用模式^HTTP/%S*%s(%d)匹配HTTP/1.1 200 OK这类行把第一处匹配的200作为status其余非空行收进headersbody则由plenary.functional的F.join把所有 stdout 行拼成字符串。解析完成后会立即vim.loop.fs_unlink删除临时头文件。2.3 七个方法入口模块末尾plenary_curl.md#L339-L364通过partial闭包生成了七个方法return { get partial get, post partial post, put partial put, head partial head, patch partial patch, delete partial delete, request partial request, }partial的实现有两点值得注意既支持Curl.get(url, opts)也支持直接把url放进 opts 表、整体传参Curl.get({ url ..., ... })opts method request and opts or vim.tbl_extend(keep, opts, spec)除request外的所有方法会把method字段合并进参数表而request方法要求用户自行通过method参数指定或使用 opts 表时自动带上。三、参数如何变成 curl 命令底层拼装机制这是 Plenary.Curl 最核心、也最值得深读的部分。所有参数都会在 parse.request 中被逐项翻译成 curl 的 argv最终结果形如-sSL dump [--insecure] [--proxy ...] [--compressed] [-X METHOD] [-H K: V] ... [-d kv] [-F kv] [-d file] [-u user:pass] [--http2] [raw...] [-o out] url3.1 body 参数的三态分派body是灵活性最高的参数parse.request 开头 对它做了三种分派if type(b) table then opts.data b -- 1. table → 作为 -d keyvalue 表单数据 elseif silent_is_file() then opts.in_file b -- 2. 字符串且指向真实文件 → -d file文件内容 elseif type(b) string then opts.raw_body b -- 3. 普通字符串 → --data-raw 原样发送 end注意这里的silent_is_file使用pcall(P.is_file, ...)包裹即使传入的不是文件路径也不会抛错而是安全回退到原始字符串分支。CodeCompanion 正是利用「body 可以是指向文件的路径」这一特性把 JSON 请求体先写入临时文件再交给 curl见下文第四节。3.2 各 parse 函数的翻译规则源码中的解析函数逐一对应着 curl 参数参数/场景翻译结果对应函数headers表-H Header-Name: value下划线转连字符、首字母大写parse.headersaccept-H Accept: 值parse.accept_headerdata表-d keyvalue每个键值对一条parse.data_bodyraw_body字符串--data-raw 值parse.raw_bodyform表-F keyvalueparse.formquery表key1value1key2value2追加到 url 后用?连接parse.curl_queryparse.urlmethod非 head-X 大写方法名parse.methodmethod head-IHEAD 请求专用旗标parse.methodin_file-d 绝对路径parse.fileauth-u user:pass或-u user:passparse.authhttp_versionHTTP/2→--http2校验后小写并去掉/parse.http_versioninsecure--insecureparse.request内联proxy--proxy 值parse.request内联output-o 路径parse.request内联值得一提的细节基础参数固定为-sSLplenary_curl.md#L222即静默模式 跟随重定向 显示错误parse.http_version会校验取值传入未知版本直接error Unknown HTTP version.parse.url对 table 类型的 url 直接报错error Low level URL definition is not supported.低层 URL 定义不被支持parse.headers做规范化content_type→Content-Type即把下划线换成连字符并按词首大写处理。3.3 响应头转储与gen_dump_path为了拿到响应头Plenary.Curl 会让 curl 用-D把响应头写入临时文件util.gen_dump_pathplenary_curl.md#L77-L90。临时文件路径规则Windows%USERPROFILE%\AppData\Local\Temp\plenary_curl_id.headers其他平台$XDG_RUNTIME_DIR未设置则/tmp下的plenary_curl_id.headers。id由math.random生成的十六进制串填充避免并发请求互相覆盖。3.4 默认值合并正式发请求前plenary_curl.md#L283-L289会用vim.tbl_extend(force, {...}, specs)合并默认值local args, opts parse.request(vim.tbl_extend(force, { compressed package.config:sub(1, 1) ~ \\, -- 非 Windows 默认启用压缩 dry_run false, dump util.gen_dump_path(), }, specs))即默认启用--compressedWindows 除外、默认dry_run false、自动生成响应头转储文件。dry_run true时request直接返回 args 数组方便调试——这一特性对排查请求问题非常有用。四、同步与异步两种调用范式request 主体 基于plenary.job构建任务执行命令取自全局变量vim.g.plenary_curl_bin_path未设置时回退为curl——这意味着用户可以自定义 curl 二进制路径。4.1 异步模式推荐不阻塞 Neovim只要传了callback或stream就进入异步模式Curl.get(https://api.example.com/v1/models, { headers { Authorization Bearer .. token }, callback function(response) -- response.status / response.headers / response.body local ok, json pcall(vim.json.decode, response.body) end, })此时job:start()立即返回 job 对象Neovim 事件循环不被阻塞。若传入stream每次 stdout 输出都会回调CodeCompanion 的 SSE 流式响应正是借助这一机制实现的。curl 退出码非 0 时若提供了on_error则调用它否则直接error()错误信息包含方法、URL、退出码与 stderr 内容plenary_curl.md#L304-L317。4.2 同步模式不传回调时走同步路径job:sync(timeout)默认超时10000毫秒plenary_curl.md#L331返回解析后的响应 table。适合工具脚本、模型列表拉取等一次性调用场景。4.3 在 CodeCompanion 中的实践仓库对两种模式都有真实用例同步copilot/stats.lua 用Curl.get(https://api.github.com/copilot_internal/user, { sync true, ... })拉取 Copilot 用量统计随后vim.json.decode(response.body)解析额度快照异步回调adapters/utils/models/fetch.lua 用Curl.get(url, { callback vim.schedule_wrap(...) })异步拉取模型列表配合vim.wait实现「先异步发起、必要时阻塞等待」的混合策略流式http.lua 为流式请求设置request_opts[stream] self.methods.schedule_wrap(...)逐块接收 SSE 数据并写入响应日志文件。五、CodeCompanion.nvim 如何站在 Plenary.Curl 之上理解 Plenary.Curl 后再看 CodeCompanion 的 HTTP 层就一目了然了。5.1 统一 HTTP 客户端http.lualua/codecompanion/http.lua 是核心封装开头即local Curl require(plenary.curl)并通过静态方法表便于测试 mockClient.static.methods { post { default Curl.post }, get { default Curl.get }, ... }它做了几件 Plenary.Curl 本身不负责的事请求体写临时文件write_body_file用vim.fn.tempname() .. .json生成临时文件把编码后的 JSON body 写进去再以body body_file传给 Curl——正好命中 Plenary.Curl 的「body 是文件路径」分支请求头写文件write_headers_file把 headers 逐行写入--header file所需的文件附加 curl 原始参数build_curl_args注入--retry 3 --retry-delay 1 --keepalive-time 60 --connect-timeout 10流式时再加--tcp-nodelay --no-buffer并通过raw参数透传给 Plenary.Curl错误处理HTTP 状态码 ≥ 400 时把响应包装为{ message, stderr, status }错误。5.2 GitHub Copilot 适配器Copilot 相关的两处调用直观展示了 Plenary.Curl 的典型用法copilot/token.luaCurl.get(https://api.github.com/copilot_internal/v2/token, { headers { Authorization Bearer .. oauth }, on_error ... })换取 Copilot 会话 Token并设置_token_fetch_in_progress锁避免并发重复请求copilot/stats.lua携带Authorization、Accept: */*、User-Agent三个头同步获取用量数据。5.3 Ollama 模型列表ollama/get_models.lua 是异步嵌套的典型先Curl.get(url .. /api/tags, { callback ... })拉模型清单在回调里再对每个模型发起Curl.post(url .. /api/show, { body vim.json.encode({ model name }) })并维护pending表与_running标志来控制并发与完成判定。这正是「基于 Plenary.Curl 的回调式编程」的生动范例。5.4 远程图片下载utils/images.lua 展示了output参数的实际价值Curl.get(url, { output loc, callback ... })把图片直接下载到临时文件再从响应头中解析Content-Type得到 mimetype进而 base64 编码后发给多模态模型。六、实用技巧与注意事项结合源码实现总结几条实战经验调试用dry_run遇到请求异常时设dry_run true拿到完整 argv 数组可以直接在 shell 里复现local args Curl.post({ url https://..., body {...}, dry_run true }) print(vim.inspect(args))响应头在headers里是字符串行如需结构化取值可像 utils/images.lua 那样用line:match(^([^:]):%s*(.)$)自行解析键值。body传文件路径可避免大请求体占用内存CodeCompanion 的 JSON 请求体就采用写临时文件的方式这也是 Plenary.Curl 三态分派设计的初衷。流式响应务必包一层vim.schedule_wrap回调中直接操作 buffer/extmark 等 Neovim API 时应像 http.lua 那样调度回主循环避免在 job 的线程回调中触发 API 竞态。同步调用注意超时默认 10 秒超时对模型推理类请求可能不够务必显式传timeout毫秒。CodeCompanion 在 http.lua 的 send_sync 中默认给了 120000 毫秒。自定义 curl 路径通过vim.g.plenary_curl_bin_path可替换默认的curl二进制适合受限环境或需要特定版本的场景。七、小结Plenary.Curl 的价值在于用一张参数表统一了 curl 的近百个命令行旗标用plenary.job提供了不阻塞 Neovim 的异步能力再用统一的{ exit, status, headers, body }响应结构抹平了底层差异。CodeCompanion.nvim 的 HTTP 适配器体系、Copilot 令牌管理、Ollama 模型发现乃至图片拉取全部建立在这层薄薄的封装之上。掌握了本文的参数模型、翻译规则与同步/异步范式无论是排查 CodeCompanion 的网络问题还是在自己基于 plenary.nvim 的插件中发起 HTTP 请求都将事半功倍。【免费下载链接】codecompanion.nvim✨ AI Coding, Vim Style项目地址: https://gitcode.com/GitHub_Trending/co/codecompanion.nvim创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考