尧图网页设计 
深入解析 go-openapi/jsonreferenceBuildKit 内 JSON Reference 的 Go 实现与解析原理【免费下载链接】buildkitconcurrent, cache-efficient, and Dockerfile-agnostic builder toolkit项目地址: https://gitcode.com/GitHub_Trending/bu/buildkit本篇技术指南以 go-openapi/jsonreference 的 README 为核心骨架结合其源码reference.go、normalize_url.go以及它在 BuildKit 仓库中的实际引入方式go.mod 间接依赖、go-openapi/spec 的消费场景完整讲解 Go 语言中 JSON Reference 的解析、继承解析与 URL 规范化机制。读完本文你将掌握New/MustCreateRef/Inherits等核心 API 的语义、Ref结构体五种形态标志的判定规则以及 OpenAPI/Swagger 工具链中$ref引用是如何被解析与序列化的并能在自己的 Go 项目中正确使用该库。一、库定位一个面向 Go 的 JSON Reference 实现jsonreference是 go-openapi 生态中的一个基础组件README 用一句话定义了它的使命An implementation of JSON Reference for golang一个 Go 语言的 JSON Reference 实现。JSON Reference 是 OpenAPISwagger规范描述文档间引用关系所依赖的机制它允许一个 JSON 文档通过形如#/definitions/Pet的指针或http://example.com/doc.json#/definitions/Pet的完整 URL 指向另一个文档中的某个节点从而实现 Schema 复用与拆分布局。从 README 的Status一节可以确认该库API is stableAPI 稳定这意味着在项目中可以直接放心引入而不必担心接口频繁变动。README 还明确了其唯一外部依赖jsonpointer负责 JSON PointerRFC 6901 风格的#/definitions/Pet片段的解析与定位。在 BuildKit 仓库中的角色需要特别说明的是jsonreference在 BuildKit 中并不是业务代码直接调用的库而是作为**间接依赖indirect**被引入的。证据如下go.mod 第 164 行声明github.com/go-openapi/jsonreference v0.21.6 // indirect同区域的github.com/go-openapi/spec、github.com/go-openapi/analysis等均以 indirect 方式引入该库以完整源码形式固化在 vendor 目录 中与LICENSE、NOTICE一并提交供离线构建使用真正消费它的是 go-openapi/spec 的 ref.go该文件在解析 OpenAPI 文档时通过jsonreference.New与jsonreference.MustCreateRef构造引用对象见 ref.go 第 40、51、175 行。也就是说BuildKit 依赖 OpenAPI 工具链用于其 API/CLI 的规格描述与校验而 OpenAPI 工具链依赖jsonreference完成$ref的底层解析。理解本库有助于理解 BuildKit 中 Swagger/OpenAPI 相关工具链如buildctl针对 worker API 的文档与类型生成的工作原理。二、安装与依赖按照 README 的指引在任何 Go 项目含 BuildKit 这类使用 vendor 的仓库中引入该库只需go get github.com/go-openapi/jsonreference依赖关系非常简单仅依赖github.com/go-openapi/jsonpointer一个库。在 BuildKit 仓库中两者成对出现在 go.mod 的 indirect 依赖区版本对应关系为jsonreference v0.21.6与jsonpointer v0.23.1。三、核心 API 与基本用法README 给出了三段最基础、最常用的代码这也是任何使用者上手的入口。下面逐段展开并结合源码解释其语义。3.1 创建一个新的引用// Creating a new reference ref, err : jsonreference.New(http://example.com/doc.json#/definitions/Pet)New是主要的构造入口它接收一个 JSON Reference 字符串返回(Ref, error)。从 reference.go 第 34-39 行 可以看到其实现func New(jsonReferenceString string) (Ref, error) { var r Ref err : r.parse(jsonReferenceString) return r, err }它内部调用url.Parse解析字符串随后执行 URL 规范化并解析片段fragment为 JSON Pointer。任何非法的 URI 或无法解析的 URL 都会返回 error因此调用方应当检查错误。3.2 仅含片段fragment-only的引用// Fragment-only reference fragRef : jsonreference.MustCreateRef(#/definitions/Pet)MustCreateRef是New的无错误版本从 reference.go 第 42-50 行 可见解析失败时直接panic(err)。它的适用场景是引用字符串在编译期或逻辑上已经确定合法例如代码中写死的常量引用。否则更推荐New并在调用方优雅处理错误。注意#/definitions/Pet这类写法字符串以#开头、没有 scheme 与路径解析后会落在HasFragmentOnly true分支见下文五种形态标志GetURL()返回的*url.URL中Fragment为/definitions/PetreferencePointer则是由jsonpointer.New解析出的指针对象。3.3 引用继承Inherits与解析// Resolving references parent, _ : jsonreference.New(http://example.com/base.json) child, _ : jsonreference.New(#/definitions/Pet) resolved, _ : parent.Inherits(child) // Result: http://example.com/base.json#/definitions/Pet这是整个库最核心的语义将子引用相对父引用进行合并继承解析。上述代码的最终结果是http://example.com/base.json#/definitions/Pet即父文档的 URL 与子引用的片段拼接成完整引用。这在 OpenAPI 文档拆分成多个文件、$ref只写相对片段时至关重要。其实现位于 reference.go 第 88-105 行func (r *Ref) Inherits(child Ref) (*Ref, error) { childURL : child.GetURL() parentURL : r.GetURL() if childURL nil { return nil, ErrChildURL } if parentURL nil { return child, nil } ref, err : New(parentURL.ResolveReference(childURL).String()) if err ! nil { return nil, err } return ref, nil }关键设计点若子引用没有 URLchildURL nil返回预定义的错误ErrChildURLreference.go 第 20 行若父引用没有 URL则直接返回子引用本身否则借助 Go 标准库net/url.URL.ResolveReference完成 RFC 3986 语义的相对引用解析再通过New重新解析并规范化返回一个新的*Ref。url.ResolveReference天然处理了子片段替换父片段子路径相对父路径子查询覆盖父查询等所有情况因此Inherits的语义与标准 URL 解析完全一致这正是 JSON Reference 草案要求的行为。四、Ref 结构体与五种形态标志Ref是库的核心数据结构reference.go 第 22-32 行 定义了它的完整形态type Ref struct { referenceURL *url.URL referencePointer jsonpointer.Pointer HasFullURL bool HasURLPathOnly bool HasFragmentOnly bool HasFileScheme bool HasFullFilePath bool }其中referenceURL保存规范化后的 URLreferencePointer保存 JSON Pointer其余五个 bool 字段描述引用的形态分类由解析器在 parse 方法 中判定标志判定条件源码典型示例HasFullURLScheme ! Host ! http://example.com/doc.json#/definitions/PetHasURLPathOnly无 scheme/host 但Path ! doc.json#/definitions/Pet、./other/spec.jsonHasFragmentOnly无 path、无 query 且 fragment 非空#/definitions/PetHasFileSchemeScheme filefile:///etc/specs/pet.jsonHasFullFilePathPath以/开头file:///etc/specs/pet.json这些标志为上层如 go-openapi/spec 的IsValidURI提供了该引用是远程 URL、本地相对路径还是纯片段的类型判断基础。例如 spec/ref.go 第 76-104 行 的IsValidURI就依据HasFullURL决定走 HTTP 探测、依据HasURLPathOnly/HasFullFilePath决定走本地文件存在性检查。五、URL 规范化从 purell 到内置 NormalizeURL解析 URL 之后、存储之前parse会调用internal.NormalizeURL对 URL 做规范化。这一设计有个历史背景在 normalize_url.go 第 23-28 行 的注释中写得很清楚旧版本依赖已停止维护的 purell 库purell.NormalizeURL现在改为内置实现行为保持一致。规范化包含四步normalize_url.go 第 36-44 行小写化 schemelowercaseSchemeHTTP://→http://小写化 hostlowercaseHostEXAMPLE.COM→example.com移除默认端口removeDefaultPorthttp://host:80去掉:80https://host:443去掉:443折叠重复斜杠removeDuplicateSlashes//a//b→/a/b。最后还会清空RawPath与RawFragmentnormalize_url.go 第 42-43 行强制 URL 以编码后的规范形式保存确保语义相同但写法不同的两个引用可以归一为同一个字符串——这是引用去重、缓存与比较正确性的前提。六、Ref 的常用方法除了New/MustCreateRef/InheritsREADME 虽未逐一列出但源码提供了完整的方法集实际使用中同样高频GetURL() *url.URLreference.go 第 52-55 行返回底层 URL 对象供上层拼接、探测或读取片段GetPointer() *jsonpointer.Pointerreference.go 第 57-60 行返回解析好的 JSON Pointer用于在目标文档中定位节点String() stringreference.go 第 62-73 行返回最佳形式的字符串——优先返回完整 URL仅片段引用则返回# 指针否则返回指针字符串IsRoot() boolreference.go 第 75-81 行判断是否为根文档引用要求有 URL、非 canonical、非纯路径形式且无片段IsCanonical() boolreference.go 第 83-86 行判断引用是否以http(s)://或file://开头即是否已是绝对规范形式。这些方法共同支撑了 go-openapi/spec 中Ref的完整行为例如 ref.go 的MarshalJSON输出{$ref: ...}结构、RemoteURI剥离 fragment 得到纯远程地址等都是建立在上述基础方法之上。七、在 OpenAPI 工具链中的典型用法理解了 jsonreference 本身再看它在 go-openapi/spec 的 ref.go 中的包装会非常直观。spec.Ref直接内嵌jsonreference.Reftype Ref struct { jsonreference.Ref }NewRef(refURI)委托jsonreference.New解析失败即返回错误ref.go 第 39-46 行MustCreateRef(refURI)委托jsonreference.MustCreateRefref.go 第 50-52 行IsValidURI(basepaths...)基于HasFullURL/HasURLPathOnly/HasFileScheme等标志决定远程 HTTP 探测还是本地文件校验ref.go 第 66-112 行UnmarshalJSON从{$ref: ...}中提取字符串并再次交给jsonreference.New完成解析ref.go 第 138-144 行与 168-183 行。也就是说当 BuildKit 或其相关工具加载 OpenAPI 规格、遇到$ref字段时底层实际上就是 jsonreference 在完成字符串 → Ref → URL Pointer的解析链路。八、实战建议与注意事项综合 README 与源码给出以下可直接落地的使用建议优先使用New处理外部输入引用字符串来自配置文件、用户输入或网络文档时必须处理 error避免MustCreateRef的 panic 击穿服务仅在字面量常量如代码中硬编码的#/definitions/Pet场景使用MustCreateRef。理解Inherits的单向性parent.Inherits(child)的语义是子引用继承父引用父提供基础 URL子提供相对片段或路径。不要弄反父子关系否则解析结果会与预期相悖。善用形态标志做分支处理在实现引用加载器时先检查HasFullURL远程拉取、HasFileScheme本地文件、HasFragmentOnly同文档内定位、HasURLPathOnly相对路径定位再决定加载策略——这正是 spec.Ref 的IsValidURI的设计思路。规范化保证可比较性依赖内置NormalizeURL小写 scheme/host、去默认端口、折叠斜杠两个写法不同的等价引用如HTTP://HOST:80/a//b与http://host/a/b最终会归一为同一字符串可用于去重与缓存键。关注版本与许可当前仓库锁定的是v0.21.6见 go.mod该库以 Apache-2.0 协议发布见 LICENSE可放心在商业项目中使用由于 API 稳定跨版本升级风险低。九、规范依据与延伸阅读JSON Reference 本身依据两份 IETF 草案JSON Pointer对应 JSON Pointer 语法被用于#/definitions/Pet片段与 JSON Reference定义$ref引用语义README 的References一节对此有明确指向。若希望继续深入本库源码reference.go解析与继承、internal/normalize_url.goURL 规范化依赖库 jsonpointervendor/github.com/go-openapi/jsonpointer/消费方示例go-openapi/spec 的 ref.go$ref的包装、校验与序列化引入关系go.modBuildKit 中jsonreference v0.21.6为间接依赖。总体来看go-openapi/jsonreference是一个小而精的库对外只暴露Ref类型与New/MustCreateRef/Inherits三个构造/解析入口对内则通过标准库net/url与内置规范化逻辑把 JSON Reference 的解析、继承与归一化全部收敛在一个文件中。它不直接参与 BuildKit 的构建求解却为 BuildKit 依赖的 OpenAPI 工具链提供了坚实可靠的引用解析地基。【免费下载链接】buildkitconcurrent, cache-efficient, and Dockerfile-agnostic builder toolkit项目地址: https://gitcode.com/GitHub_Trending/bu/buildkit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 深入解析 go-openapi/jsonreference：BuildKit 内 JSON Reference 的 Go 实现与解析原理
深入解析 go-openapi/jsonreferenceBuildKit 内 JSON Reference 的 Go 实现与解析原理【免费下载链接】buildkitconcurrent, cache-efficient, and Dockerfile-agnostic builder toolkit项目地址: https://gitcode.com/GitHub_Trending/bu/buildkit本篇技术指南以 go-openapi/jsonreference 的 README 为核心骨架结合其源码reference.go、normalize_url.go以及它在 BuildKit 仓库中的实际引入方式go.mod 间接依赖、go-openapi/spec 的消费场景完整讲解 Go 语言中 JSON Reference 的解析、继承解析与 URL 规范化机制。读完本文你将掌握New/MustCreateRef/Inherits等核心 API 的语义、Ref结构体五种形态标志的判定规则以及 OpenAPI/Swagger 工具链中$ref引用是如何被解析与序列化的并能在自己的 Go 项目中正确使用该库。一、库定位一个面向 Go 的 JSON Reference 实现jsonreference是 go-openapi 生态中的一个基础组件README 用一句话定义了它的使命An implementation of JSON Reference for golang一个 Go 语言的 JSON Reference 实现。JSON Reference 是 OpenAPISwagger规范描述文档间引用关系所依赖的机制它允许一个 JSON 文档通过形如#/definitions/Pet的指针或http://example.com/doc.json#/definitions/Pet的完整 URL 指向另一个文档中的某个节点从而实现 Schema 复用与拆分布局。从 README 的Status一节可以确认该库API is stableAPI 稳定这意味着在项目中可以直接放心引入而不必担心接口频繁变动。README 还明确了其唯一外部依赖jsonpointer负责 JSON PointerRFC 6901 风格的#/definitions/Pet片段的解析与定位。在 BuildKit 仓库中的角色需要特别说明的是jsonreference在 BuildKit 中并不是业务代码直接调用的库而是作为**间接依赖indirect**被引入的。证据如下go.mod 第 164 行声明github.com/go-openapi/jsonreference v0.21.6 // indirect同区域的github.com/go-openapi/spec、github.com/go-openapi/analysis等均以 indirect 方式引入该库以完整源码形式固化在 vendor 目录 中与LICENSE、NOTICE一并提交供离线构建使用真正消费它的是 go-openapi/spec 的 ref.go该文件在解析 OpenAPI 文档时通过jsonreference.New与jsonreference.MustCreateRef构造引用对象见 ref.go 第 40、51、175 行。也就是说BuildKit 依赖 OpenAPI 工具链用于其 API/CLI 的规格描述与校验而 OpenAPI 工具链依赖jsonreference完成$ref的底层解析。理解本库有助于理解 BuildKit 中 Swagger/OpenAPI 相关工具链如buildctl针对 worker API 的文档与类型生成的工作原理。二、安装与依赖按照 README 的指引在任何 Go 项目含 BuildKit 这类使用 vendor 的仓库中引入该库只需go get github.com/go-openapi/jsonreference依赖关系非常简单仅依赖github.com/go-openapi/jsonpointer一个库。在 BuildKit 仓库中两者成对出现在 go.mod 的 indirect 依赖区版本对应关系为jsonreference v0.21.6与jsonpointer v0.23.1。三、核心 API 与基本用法README 给出了三段最基础、最常用的代码这也是任何使用者上手的入口。下面逐段展开并结合源码解释其语义。3.1 创建一个新的引用// Creating a new reference ref, err : jsonreference.New(http://example.com/doc.json#/definitions/Pet)New是主要的构造入口它接收一个 JSON Reference 字符串返回(Ref, error)。从 reference.go 第 34-39 行 可以看到其实现func New(jsonReferenceString string) (Ref, error) { var r Ref err : r.parse(jsonReferenceString) return r, err }它内部调用url.Parse解析字符串随后执行 URL 规范化并解析片段fragment为 JSON Pointer。任何非法的 URI 或无法解析的 URL 都会返回 error因此调用方应当检查错误。3.2 仅含片段fragment-only的引用// Fragment-only reference fragRef : jsonreference.MustCreateRef(#/definitions/Pet)MustCreateRef是New的无错误版本从 reference.go 第 42-50 行 可见解析失败时直接panic(err)。它的适用场景是引用字符串在编译期或逻辑上已经确定合法例如代码中写死的常量引用。否则更推荐New并在调用方优雅处理错误。注意#/definitions/Pet这类写法字符串以#开头、没有 scheme 与路径解析后会落在HasFragmentOnly true分支见下文五种形态标志GetURL()返回的*url.URL中Fragment为/definitions/PetreferencePointer则是由jsonpointer.New解析出的指针对象。3.3 引用继承Inherits与解析// Resolving references parent, _ : jsonreference.New(http://example.com/base.json) child, _ : jsonreference.New(#/definitions/Pet) resolved, _ : parent.Inherits(child) // Result: http://example.com/base.json#/definitions/Pet这是整个库最核心的语义将子引用相对父引用进行合并继承解析。上述代码的最终结果是http://example.com/base.json#/definitions/Pet即父文档的 URL 与子引用的片段拼接成完整引用。这在 OpenAPI 文档拆分成多个文件、$ref只写相对片段时至关重要。其实现位于 reference.go 第 88-105 行func (r *Ref) Inherits(child Ref) (*Ref, error) { childURL : child.GetURL() parentURL : r.GetURL() if childURL nil { return nil, ErrChildURL } if parentURL nil { return child, nil } ref, err : New(parentURL.ResolveReference(childURL).String()) if err ! nil { return nil, err } return ref, nil }关键设计点若子引用没有 URLchildURL nil返回预定义的错误ErrChildURLreference.go 第 20 行若父引用没有 URL则直接返回子引用本身否则借助 Go 标准库net/url.URL.ResolveReference完成 RFC 3986 语义的相对引用解析再通过New重新解析并规范化返回一个新的*Ref。url.ResolveReference天然处理了子片段替换父片段子路径相对父路径子查询覆盖父查询等所有情况因此Inherits的语义与标准 URL 解析完全一致这正是 JSON Reference 草案要求的行为。四、Ref 结构体与五种形态标志Ref是库的核心数据结构reference.go 第 22-32 行 定义了它的完整形态type Ref struct { referenceURL *url.URL referencePointer jsonpointer.Pointer HasFullURL bool HasURLPathOnly bool HasFragmentOnly bool HasFileScheme bool HasFullFilePath bool }其中referenceURL保存规范化后的 URLreferencePointer保存 JSON Pointer其余五个 bool 字段描述引用的形态分类由解析器在 parse 方法 中判定标志判定条件源码典型示例HasFullURLScheme ! Host ! http://example.com/doc.json#/definitions/PetHasURLPathOnly无 scheme/host 但Path ! doc.json#/definitions/Pet、./other/spec.jsonHasFragmentOnly无 path、无 query 且 fragment 非空#/definitions/PetHasFileSchemeScheme filefile:///etc/specs/pet.jsonHasFullFilePathPath以/开头file:///etc/specs/pet.json这些标志为上层如 go-openapi/spec 的IsValidURI提供了该引用是远程 URL、本地相对路径还是纯片段的类型判断基础。例如 spec/ref.go 第 76-104 行 的IsValidURI就依据HasFullURL决定走 HTTP 探测、依据HasURLPathOnly/HasFullFilePath决定走本地文件存在性检查。五、URL 规范化从 purell 到内置 NormalizeURL解析 URL 之后、存储之前parse会调用internal.NormalizeURL对 URL 做规范化。这一设计有个历史背景在 normalize_url.go 第 23-28 行 的注释中写得很清楚旧版本依赖已停止维护的 purell 库purell.NormalizeURL现在改为内置实现行为保持一致。规范化包含四步normalize_url.go 第 36-44 行小写化 schemelowercaseSchemeHTTP://→http://小写化 hostlowercaseHostEXAMPLE.COM→example.com移除默认端口removeDefaultPorthttp://host:80去掉:80https://host:443去掉:443折叠重复斜杠removeDuplicateSlashes//a//b→/a/b。最后还会清空RawPath与RawFragmentnormalize_url.go 第 42-43 行强制 URL 以编码后的规范形式保存确保语义相同但写法不同的两个引用可以归一为同一个字符串——这是引用去重、缓存与比较正确性的前提。六、Ref 的常用方法除了New/MustCreateRef/InheritsREADME 虽未逐一列出但源码提供了完整的方法集实际使用中同样高频GetURL() *url.URLreference.go 第 52-55 行返回底层 URL 对象供上层拼接、探测或读取片段GetPointer() *jsonpointer.Pointerreference.go 第 57-60 行返回解析好的 JSON Pointer用于在目标文档中定位节点String() stringreference.go 第 62-73 行返回最佳形式的字符串——优先返回完整 URL仅片段引用则返回# 指针否则返回指针字符串IsRoot() boolreference.go 第 75-81 行判断是否为根文档引用要求有 URL、非 canonical、非纯路径形式且无片段IsCanonical() boolreference.go 第 83-86 行判断引用是否以http(s)://或file://开头即是否已是绝对规范形式。这些方法共同支撑了 go-openapi/spec 中Ref的完整行为例如 ref.go 的MarshalJSON输出{$ref: ...}结构、RemoteURI剥离 fragment 得到纯远程地址等都是建立在上述基础方法之上。七、在 OpenAPI 工具链中的典型用法理解了 jsonreference 本身再看它在 go-openapi/spec 的 ref.go 中的包装会非常直观。spec.Ref直接内嵌jsonreference.Reftype Ref struct { jsonreference.Ref }NewRef(refURI)委托jsonreference.New解析失败即返回错误ref.go 第 39-46 行MustCreateRef(refURI)委托jsonreference.MustCreateRefref.go 第 50-52 行IsValidURI(basepaths...)基于HasFullURL/HasURLPathOnly/HasFileScheme等标志决定远程 HTTP 探测还是本地文件校验ref.go 第 66-112 行UnmarshalJSON从{$ref: ...}中提取字符串并再次交给jsonreference.New完成解析ref.go 第 138-144 行与 168-183 行。也就是说当 BuildKit 或其相关工具加载 OpenAPI 规格、遇到$ref字段时底层实际上就是 jsonreference 在完成字符串 → Ref → URL Pointer的解析链路。八、实战建议与注意事项综合 README 与源码给出以下可直接落地的使用建议优先使用New处理外部输入引用字符串来自配置文件、用户输入或网络文档时必须处理 error避免MustCreateRef的 panic 击穿服务仅在字面量常量如代码中硬编码的#/definitions/Pet场景使用MustCreateRef。理解Inherits的单向性parent.Inherits(child)的语义是子引用继承父引用父提供基础 URL子提供相对片段或路径。不要弄反父子关系否则解析结果会与预期相悖。善用形态标志做分支处理在实现引用加载器时先检查HasFullURL远程拉取、HasFileScheme本地文件、HasFragmentOnly同文档内定位、HasURLPathOnly相对路径定位再决定加载策略——这正是 spec.Ref 的IsValidURI的设计思路。规范化保证可比较性依赖内置NormalizeURL小写 scheme/host、去默认端口、折叠斜杠两个写法不同的等价引用如HTTP://HOST:80/a//b与http://host/a/b最终会归一为同一字符串可用于去重与缓存键。关注版本与许可当前仓库锁定的是v0.21.6见 go.mod该库以 Apache-2.0 协议发布见 LICENSE可放心在商业项目中使用由于 API 稳定跨版本升级风险低。九、规范依据与延伸阅读JSON Reference 本身依据两份 IETF 草案JSON Pointer对应 JSON Pointer 语法被用于#/definitions/Pet片段与 JSON Reference定义$ref引用语义README 的References一节对此有明确指向。若希望继续深入本库源码reference.go解析与继承、internal/normalize_url.goURL 规范化依赖库 jsonpointervendor/github.com/go-openapi/jsonpointer/消费方示例go-openapi/spec 的 ref.go$ref的包装、校验与序列化引入关系go.modBuildKit 中jsonreference v0.21.6为间接依赖。总体来看go-openapi/jsonreference是一个小而精的库对外只暴露Ref类型与New/MustCreateRef/Inherits三个构造/解析入口对内则通过标准库net/url与内置规范化逻辑把 JSON Reference 的解析、继承与归一化全部收敛在一个文件中。它不直接参与 BuildKit 的构建求解却为 BuildKit 依赖的 OpenAPI 工具链提供了坚实可靠的引用解析地基。【免费下载链接】buildkitconcurrent, cache-efficient, and Dockerfile-agnostic builder toolkit项目地址: https://gitcode.com/GitHub_Trending/bu/buildkit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考