typespec/http-client-java 版本演进全解读0.7.0 → 0.8.1 的关键能力、修复与 Java 客户端生成实践【免费下载链接】typespec项目地址: https://gitcode.com/GitHub_Trending/ty/typespectypespec/http-client-java是 TypeSpec 生态中负责从 TypeSpec REST 协议绑定生成 Java 客户端代码的核心 emitter。本文以仓库内 CHANGELOG.md 为主线逐条剖析 0.7.0、0.8.0、0.8.1 三个版本在 Duration 编码、API 版本元数据、JSON Merge Patch、文件类型、分页、XML 序列化等方向上的功能增强与缺陷修复并结合 emitter/src 与 generator 源码讲清每个变更背后的实现机制。读完本文你将掌握该 emitter 的版本差异、各能力对应的 TypeSpec 写法以及如何正确配置 emitter 选项来生成符合预期的 Java 客户端。一、版本脉络与整体定位typespec/http-client-java仓库位于packages/http-client-java结构上分为两个核心部分emitteremitter/srcTypeScript 实现负责把 TypeSpec 程序编译为中间代码模型code model核心入口是 code-model-builder.ts诊断定义集中在 lib.ts。generatorJava 实现负责把 code model 渲染为最终 Java 源码例如 XML 序列化相关的属性映射逻辑位于generator/http-client-generator-core/src/main/java/com/microsoft/typespec/http/client/generator/core/mapper/ModelPropertyMapper.java。从 CHANGELOG 的版本节奏看三个版本呈现清晰的演进主线0.7.0 补齐 File 类型支持并升级底层依赖TCGC 至 0.65.10.8.0 集中增强 Duration 编码、API 版本元数据、JSON Merge Patch 诊断与 clientRequired 客户端选项0.8.1 则针对 clientRequired 引入严格的错误校验。下文按版本逐一展开。二、0.8.1clientRequired仅允许设置为true0.8.1 只有一个修复项当属性上的clientRequired被显式设置为false时emitter 会直接报告编译错误PR #10365。2.1 实现原理在 code-model-builder.ts 中属性是否必填的判断逻辑如下private isPropertyRequired(property: { optional: boolean } DecoratedType): boolean { const clientRequired getClientOptions(property, clientRequired) as boolean; if (clientRequired false) { reportDiagnostic(this.program, { code: client-required-false, target: (property as any).__raw ?? NoTarget, }); } return clientRequired ?? !property.optional; }可见clientRequired通过getClientOptions(property, clientRequired)读取取值逻辑为clientRequired ?? !property.optional即未设置时回退到属性自身的 optional 状态。而一旦显式传入false就会触发client-required-false诊断。2.2 诊断消息与修复方式该诊断在 lib.ts 中被定义为error 级别client-required-false: { ...doc(client-required-false), severity: error, messages: { default: Client option clientRequired can only be set to true., }, },完整的影响说明与修复示例见 diagnostics/client-required-false.md。其核心原因是在 Java 客户端模型中客户端方法参数层面无法表达“可选的必填”语义因此错误示例设置为falseop read(...ReadOptions): void; clientOption(ReadOptions.filter, clientRequired, false, java);必须改写为显式trueop read(...ReadOptions): void; clientOption(ReadOptions.filter, clientRequired, true, java);三、0.8.0 新特性详解一Duration 毫秒编码支持0.8.0 引入的最重要的类型系统能力是支持DurationKnownEncoding.millisecondsPR #9926以毫秒编码的 Duration 属性客户端类型统一使用Duration并在网络上与整数毫秒或浮点毫秒之间完成自动转换。3.1 已知编码集合在 type-utils.ts 中定义了 emitter 支持的时长编码export const DURATION_KNOWN_ENCODING [ISO8601, seconds, milliseconds];同时还有日期时间编码[rfc3339, rfc7231, unixTimestamp]与字节编码[base64, base64url]便于横向对照。3.2 毫秒编码的格式化分支在 type-utils.ts 中当type.encode milliseconds时根据 wire 类型选择具体格式} else if (type.encode milliseconds) { if (isSdkIntKind(type.wireType.kind)) { format milliseconds-integer; } else if (isSdkFloatKind(type.wireType.kind)) { format milliseconds-number; } else { throw new Error( Unrecognized scalar type used by duration encoded as milliseconds: ${type.kind}., ); } }对应的格式枚举定义在 common/schemas/time.tsseconds-integer | seconds-number | milliseconds-integer | milliseconds-number。也就是说线上传输为整数毫秒时使用milliseconds-integer线上传输为浮点毫秒时使用milliseconds-number若 wire 类型既非 int 也非 float则直接抛出异常避免生成语义错误的代码。四、0.8.0 新特性详解二apiVersions 写入 metadata.jsonPR #9725 为 emitter 增加了将 API 版本信息写入metadata.json的能力。从 code-model-builder.ts 可以看到元数据的装配过程// metadata if (this.sdkContext.sdkPackage.metadata.apiVersions) { this.codeModel.apiVersionMap Object.fromEntries( this.sdkContext.sdkPackage.metadata.apiVersions, ); } // cross-language metadata this.codeModel.crossLanguagePackageId this.sdkContext.sdkPackage.crossLanguagePackageId; this.codeModel.crossLanguageVersion this.sdkContext.sdkPackage.crossLanguageVersion;apiVersions来源于 TCGCTypeSpec Client Generator Core的sdkPackage.metadataemitter 将其转换为apiVersionMap。随后在客户端构建阶段code-model-builder.ts 会遍历getFilteredApiVersions(...)生成codeModelClient.apiVersions数组若恰好只有一个 api-version 枚举还会用该枚举的取值覆盖codeModelClient.apiVersions针对 TCGC 的已知问题做的兼容处理。这意味着版本化 API 的多版本元数据可以随生成的客户端一起落入metadata.json供下游消费。五、0.8.0 新特性详解三JSON Merge Patch 的 spread 警告PR #9844 增加了一条警告当 emitter 对application/merge-patchjson请求体执行模型 spread打散成方法参数时会提示该场景不受支持。5.1 触发点在 code-model-builder.ts 中if (jsonMergePatch) { // skip model flatten, if application/merge-patchjson reportDiagnostic(this.program, { code: spread-json-merge-patch-payload-not-supported, target: sdkMethod.__raw ?? NoTarget, }); if (sdkType.isGeneratedName) { ... } }5.2 为什么必须警告警告的完整措辞定义在 lib.tsSpread JSON merge-patch payload is not supported. The reason is that a property in JSON merge-patch payload class can: set a value; not set so that value does not change; set to null to remove the value. A parameter on method cannot distinguish the latter 2 cases.翻译过来就是JSON Merge Patch 载荷中的属性存在三种状态——设置新值、不设置值不变、显式置空删除该值而方法参数只能区分“传了”和“没传”无法表达“不设置”与“设置为 null”的差异因此打散为参数会丢失语义必须警告。同时 common/schemas/usage.ts 中新增了JsonMergePatch json-merge-patch这一 usage 标记用于标识参与 merge-patch 操作的 schema。六、0.8.0 新特性详解四clientRequired 客户端选项PR #10337 正式为 Java emitter 引入了clientRequired客户端选项即第三节中getClientOptions(property, clientRequired)的读取来源。它允许开发者通过clientOption装饰器在 TypeSpec 层面覆盖客户端参数的必填语义——但正如 0.8.1 所约束的该选项只允许设置为true。这是一个典型的“先放行、后收紧”演进案例0.8.0 引入读取逻辑0.8.1 立即补齐了非法取值的编译期拦截。七、0.8.0 缺陷修复全景0.8.0 共包含 12 项修复可按主题归类为五组便于理解其覆盖范围。7.1 类型映射与枚举alternateType应用到 enum/unionPR #9784修复了alternateType对枚举与联合类型未生效的问题确保替代类型声明能被正确映射到 Java 类型系统。text/plain内容类型允许用于 EnumPR #9993此前枚举值的传输类型受限此修复放开了text/plain场景下的枚举序列化。7.2 分页与访问控制accesspublic覆盖 PagedPR #10131当分页操作的访问级别被显式标记为public时应优先遵循该标记而非默认分页行为。结果片段 value 在父模型中定义时找不到PR #10017修复了分页结果片段如value定义在父模型中时无法正确解析的问题。7.3 命名与复数转换Caches 的单数形式错误PR #10338修复了 Caches 被错误转换单数的问题。复数转单数逻辑改进PR #9963整体提升了英文复数到单数的转换健壮性这两项直接影响生成的方法名、参数名与属性名的可读性。7.4 XML 序列化isXmlWrappertrue时 XML 数组的 bugPR #10209修复带 XML wrapper 的数组序列化错误。在 generator 侧ModelPropertyMapper.java 展示了该标志的消费方式从xmlSerializationFormat读取isWrapped()、isAttribute()、getName()、getNamespace()等属性并通过 builder 链写入xmlName、xmlWrapper、xmlAttribute、xmlNamespace等映射结果。7.5 模型、诊断与其他discriminator 属性缺失PR #10080修复了模型声明了discriminator但没有已知子类型时discriminator 属性不生成的问题。JSON 示例格式错误被忽略PR #10262示例数据格式不合法时不再导致整体失败而是静默忽略该示例。mgmt 管理的 premium samples 独立入口PR #9845为管理平面mgmt的 premium 示例拆分独立入口点。LinkedHashMap/LinkedHashSet保证迭代顺序PR #9751将生成代码中的集合类型切换为LinkedHashMap与LinkedHashSet确保多次迭代顺序一致——这对客户端输出的稳定性与可测试性至关重要。八、0.7.0File 类型支持与依赖升级0.7.0 的两项特性都围绕文件传输展开从 TypeSpec 支持FilePR #9530TypeSpec 原生File类型可以被 emitter 识别并映射为 Java 客户端中的文件类型。multipart 与请求体中的FilePR #9602在multipart/form-data以及普通请求体场景中正确承载文件内容。同版本的依赖升级集中在 TCGC 与 Node.js 工具链上TCGC 依次升级至 0.64.4 → 0.64.6 → 0.65.1PR #9472 / #9591 / #9698 / #9447Node.js 依赖更新到最新版本PR #9677。由于 emitter 的apiVersions、分页、枚举映射等能力大量依赖 TCGC 提供的sdkPackage元数据见第四节跟随 TCGC 版本演进是保证生成质量的基础。8.1 0.7.0 的修复项continuationToken变量名错误PR #9677修复分页令牌变量的命名。BinaryData类型 mock 示例值缺失PR #9527为BinaryData补齐 mock 测试中的示例值。BinaryDatamock 数据修复PR #9639进一步修正 mock 数据内容。LinkedHashMap/LinkedHashSet迭代顺序PR #9751与 0.8.0 相同的修复在 0.7.0 中已先行落地。九、从 CHANGELOG 到实战安装与配置 emitter理解版本能力后实际操作按 README.md 的说明进行。9.1 环境前提依赖版本要求校验命令Node.js20 及以上node --versionJava17 及以上java --versionMaven最新稳定版mvn --version安装 emitter 本体npm install typespec/http-client-java9.2 两种调用方式命令行方式tsp compile . --emittypespec/http-client-java配置文件方式tspconfig.yamlemit: - typespec/http-client-java带选项的扩展写法emit: - typespec/http-client-java options: typespec/http-client-java: option: value9.3 Emitter 选项速查选项类型说明emitter-output-dirabsolutePath输出目录默认值为{output-dir}/typespec/http-client-java具体规则遵循 TypeSpec 的 output-dir 配置licenseobject生成客户端代码的许可证信息dev-optionsobjectemitter 的开发者选项结合前文的变更内容建议在升级到 0.8.x 后重点验证四类场景带毫秒 Duration 的模型是否生成Duration客户端类型、版本化 API 的metadata.json是否包含apiVersions、merge-patch 操作是否出现 spread 警告、以及所有clientRequired用例是否均为true。十、总结从 0.7.0 到 0.8.1typespec/http-client-java的演进清晰体现了“能力扩展 → 语义收紧”的节奏0.7.0 打牢 File 与依赖基础0.8.0 一次性补齐 Duration 毫秒编码、apiVersions 元数据、JSON Merge Patch 诊断与clientRequired选项四大能力并修复十二项缺陷0.8.1 则把clientRequiredfalse从“可用但危险”升级为编译期错误。对于使用该 emitter 的团队本文逐条解读既可作为版本升级的验收清单也可作为排查生成代码问题的诊断手册——所有结论均可在 packages/http-client-java 的源码与测试中进一步追溯验证。【免费下载链接】typespec项目地址: https://gitcode.com/GitHub_Trending/ty/typespec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
typespec/http-client-java 版本演进全解读0.7.0 → 0.8.1 的关键能力、修复与 Java 客户端生成实践【免费下载链接】typespec项目地址: https://gitcode.com/GitHub_Trending/ty/typespectypespec/http-client-java是 TypeSpec 生态中负责从 TypeSpec REST 协议绑定生成 Java 客户端代码的核心 emitter。本文以仓库内 CHANGELOG.md 为主线逐条剖析 0.7.0、0.8.0、0.8.1 三个版本在 Duration 编码、API 版本元数据、JSON Merge Patch、文件类型、分页、XML 序列化等方向上的功能增强与缺陷修复并结合 emitter/src 与 generator 源码讲清每个变更背后的实现机制。读完本文你将掌握该 emitter 的版本差异、各能力对应的 TypeSpec 写法以及如何正确配置 emitter 选项来生成符合预期的 Java 客户端。一、版本脉络与整体定位typespec/http-client-java仓库位于packages/http-client-java结构上分为两个核心部分emitteremitter/srcTypeScript 实现负责把 TypeSpec 程序编译为中间代码模型code model核心入口是 code-model-builder.ts诊断定义集中在 lib.ts。generatorJava 实现负责把 code model 渲染为最终 Java 源码例如 XML 序列化相关的属性映射逻辑位于generator/http-client-generator-core/src/main/java/com/microsoft/typespec/http/client/generator/core/mapper/ModelPropertyMapper.java。从 CHANGELOG 的版本节奏看三个版本呈现清晰的演进主线0.7.0 补齐 File 类型支持并升级底层依赖TCGC 至 0.65.10.8.0 集中增强 Duration 编码、API 版本元数据、JSON Merge Patch 诊断与 clientRequired 客户端选项0.8.1 则针对 clientRequired 引入严格的错误校验。下文按版本逐一展开。二、0.8.1clientRequired仅允许设置为true0.8.1 只有一个修复项当属性上的clientRequired被显式设置为false时emitter 会直接报告编译错误PR #10365。2.1 实现原理在 code-model-builder.ts 中属性是否必填的判断逻辑如下private isPropertyRequired(property: { optional: boolean } DecoratedType): boolean { const clientRequired getClientOptions(property, clientRequired) as boolean; if (clientRequired false) { reportDiagnostic(this.program, { code: client-required-false, target: (property as any).__raw ?? NoTarget, }); } return clientRequired ?? !property.optional; }可见clientRequired通过getClientOptions(property, clientRequired)读取取值逻辑为clientRequired ?? !property.optional即未设置时回退到属性自身的 optional 状态。而一旦显式传入false就会触发client-required-false诊断。2.2 诊断消息与修复方式该诊断在 lib.ts 中被定义为error 级别client-required-false: { ...doc(client-required-false), severity: error, messages: { default: Client option clientRequired can only be set to true., }, },完整的影响说明与修复示例见 diagnostics/client-required-false.md。其核心原因是在 Java 客户端模型中客户端方法参数层面无法表达“可选的必填”语义因此错误示例设置为falseop read(...ReadOptions): void; clientOption(ReadOptions.filter, clientRequired, false, java);必须改写为显式trueop read(...ReadOptions): void; clientOption(ReadOptions.filter, clientRequired, true, java);三、0.8.0 新特性详解一Duration 毫秒编码支持0.8.0 引入的最重要的类型系统能力是支持DurationKnownEncoding.millisecondsPR #9926以毫秒编码的 Duration 属性客户端类型统一使用Duration并在网络上与整数毫秒或浮点毫秒之间完成自动转换。3.1 已知编码集合在 type-utils.ts 中定义了 emitter 支持的时长编码export const DURATION_KNOWN_ENCODING [ISO8601, seconds, milliseconds];同时还有日期时间编码[rfc3339, rfc7231, unixTimestamp]与字节编码[base64, base64url]便于横向对照。3.2 毫秒编码的格式化分支在 type-utils.ts 中当type.encode milliseconds时根据 wire 类型选择具体格式} else if (type.encode milliseconds) { if (isSdkIntKind(type.wireType.kind)) { format milliseconds-integer; } else if (isSdkFloatKind(type.wireType.kind)) { format milliseconds-number; } else { throw new Error( Unrecognized scalar type used by duration encoded as milliseconds: ${type.kind}., ); } }对应的格式枚举定义在 common/schemas/time.tsseconds-integer | seconds-number | milliseconds-integer | milliseconds-number。也就是说线上传输为整数毫秒时使用milliseconds-integer线上传输为浮点毫秒时使用milliseconds-number若 wire 类型既非 int 也非 float则直接抛出异常避免生成语义错误的代码。四、0.8.0 新特性详解二apiVersions 写入 metadata.jsonPR #9725 为 emitter 增加了将 API 版本信息写入metadata.json的能力。从 code-model-builder.ts 可以看到元数据的装配过程// metadata if (this.sdkContext.sdkPackage.metadata.apiVersions) { this.codeModel.apiVersionMap Object.fromEntries( this.sdkContext.sdkPackage.metadata.apiVersions, ); } // cross-language metadata this.codeModel.crossLanguagePackageId this.sdkContext.sdkPackage.crossLanguagePackageId; this.codeModel.crossLanguageVersion this.sdkContext.sdkPackage.crossLanguageVersion;apiVersions来源于 TCGCTypeSpec Client Generator Core的sdkPackage.metadataemitter 将其转换为apiVersionMap。随后在客户端构建阶段code-model-builder.ts 会遍历getFilteredApiVersions(...)生成codeModelClient.apiVersions数组若恰好只有一个 api-version 枚举还会用该枚举的取值覆盖codeModelClient.apiVersions针对 TCGC 的已知问题做的兼容处理。这意味着版本化 API 的多版本元数据可以随生成的客户端一起落入metadata.json供下游消费。五、0.8.0 新特性详解三JSON Merge Patch 的 spread 警告PR #9844 增加了一条警告当 emitter 对application/merge-patchjson请求体执行模型 spread打散成方法参数时会提示该场景不受支持。5.1 触发点在 code-model-builder.ts 中if (jsonMergePatch) { // skip model flatten, if application/merge-patchjson reportDiagnostic(this.program, { code: spread-json-merge-patch-payload-not-supported, target: sdkMethod.__raw ?? NoTarget, }); if (sdkType.isGeneratedName) { ... } }5.2 为什么必须警告警告的完整措辞定义在 lib.tsSpread JSON merge-patch payload is not supported. The reason is that a property in JSON merge-patch payload class can: set a value; not set so that value does not change; set to null to remove the value. A parameter on method cannot distinguish the latter 2 cases.翻译过来就是JSON Merge Patch 载荷中的属性存在三种状态——设置新值、不设置值不变、显式置空删除该值而方法参数只能区分“传了”和“没传”无法表达“不设置”与“设置为 null”的差异因此打散为参数会丢失语义必须警告。同时 common/schemas/usage.ts 中新增了JsonMergePatch json-merge-patch这一 usage 标记用于标识参与 merge-patch 操作的 schema。六、0.8.0 新特性详解四clientRequired 客户端选项PR #10337 正式为 Java emitter 引入了clientRequired客户端选项即第三节中getClientOptions(property, clientRequired)的读取来源。它允许开发者通过clientOption装饰器在 TypeSpec 层面覆盖客户端参数的必填语义——但正如 0.8.1 所约束的该选项只允许设置为true。这是一个典型的“先放行、后收紧”演进案例0.8.0 引入读取逻辑0.8.1 立即补齐了非法取值的编译期拦截。七、0.8.0 缺陷修复全景0.8.0 共包含 12 项修复可按主题归类为五组便于理解其覆盖范围。7.1 类型映射与枚举alternateType应用到 enum/unionPR #9784修复了alternateType对枚举与联合类型未生效的问题确保替代类型声明能被正确映射到 Java 类型系统。text/plain内容类型允许用于 EnumPR #9993此前枚举值的传输类型受限此修复放开了text/plain场景下的枚举序列化。7.2 分页与访问控制accesspublic覆盖 PagedPR #10131当分页操作的访问级别被显式标记为public时应优先遵循该标记而非默认分页行为。结果片段 value 在父模型中定义时找不到PR #10017修复了分页结果片段如value定义在父模型中时无法正确解析的问题。7.3 命名与复数转换Caches 的单数形式错误PR #10338修复了 Caches 被错误转换单数的问题。复数转单数逻辑改进PR #9963整体提升了英文复数到单数的转换健壮性这两项直接影响生成的方法名、参数名与属性名的可读性。7.4 XML 序列化isXmlWrappertrue时 XML 数组的 bugPR #10209修复带 XML wrapper 的数组序列化错误。在 generator 侧ModelPropertyMapper.java 展示了该标志的消费方式从xmlSerializationFormat读取isWrapped()、isAttribute()、getName()、getNamespace()等属性并通过 builder 链写入xmlName、xmlWrapper、xmlAttribute、xmlNamespace等映射结果。7.5 模型、诊断与其他discriminator 属性缺失PR #10080修复了模型声明了discriminator但没有已知子类型时discriminator 属性不生成的问题。JSON 示例格式错误被忽略PR #10262示例数据格式不合法时不再导致整体失败而是静默忽略该示例。mgmt 管理的 premium samples 独立入口PR #9845为管理平面mgmt的 premium 示例拆分独立入口点。LinkedHashMap/LinkedHashSet保证迭代顺序PR #9751将生成代码中的集合类型切换为LinkedHashMap与LinkedHashSet确保多次迭代顺序一致——这对客户端输出的稳定性与可测试性至关重要。八、0.7.0File 类型支持与依赖升级0.7.0 的两项特性都围绕文件传输展开从 TypeSpec 支持FilePR #9530TypeSpec 原生File类型可以被 emitter 识别并映射为 Java 客户端中的文件类型。multipart 与请求体中的FilePR #9602在multipart/form-data以及普通请求体场景中正确承载文件内容。同版本的依赖升级集中在 TCGC 与 Node.js 工具链上TCGC 依次升级至 0.64.4 → 0.64.6 → 0.65.1PR #9472 / #9591 / #9698 / #9447Node.js 依赖更新到最新版本PR #9677。由于 emitter 的apiVersions、分页、枚举映射等能力大量依赖 TCGC 提供的sdkPackage元数据见第四节跟随 TCGC 版本演进是保证生成质量的基础。8.1 0.7.0 的修复项continuationToken变量名错误PR #9677修复分页令牌变量的命名。BinaryData类型 mock 示例值缺失PR #9527为BinaryData补齐 mock 测试中的示例值。BinaryDatamock 数据修复PR #9639进一步修正 mock 数据内容。LinkedHashMap/LinkedHashSet迭代顺序PR #9751与 0.8.0 相同的修复在 0.7.0 中已先行落地。九、从 CHANGELOG 到实战安装与配置 emitter理解版本能力后实际操作按 README.md 的说明进行。9.1 环境前提依赖版本要求校验命令Node.js20 及以上node --versionJava17 及以上java --versionMaven最新稳定版mvn --version安装 emitter 本体npm install typespec/http-client-java9.2 两种调用方式命令行方式tsp compile . --emittypespec/http-client-java配置文件方式tspconfig.yamlemit: - typespec/http-client-java带选项的扩展写法emit: - typespec/http-client-java options: typespec/http-client-java: option: value9.3 Emitter 选项速查选项类型说明emitter-output-dirabsolutePath输出目录默认值为{output-dir}/typespec/http-client-java具体规则遵循 TypeSpec 的 output-dir 配置licenseobject生成客户端代码的许可证信息dev-optionsobjectemitter 的开发者选项结合前文的变更内容建议在升级到 0.8.x 后重点验证四类场景带毫秒 Duration 的模型是否生成Duration客户端类型、版本化 API 的metadata.json是否包含apiVersions、merge-patch 操作是否出现 spread 警告、以及所有clientRequired用例是否均为true。十、总结从 0.7.0 到 0.8.1typespec/http-client-java的演进清晰体现了“能力扩展 → 语义收紧”的节奏0.7.0 打牢 File 与依赖基础0.8.0 一次性补齐 Duration 毫秒编码、apiVersions 元数据、JSON Merge Patch 诊断与clientRequired选项四大能力并修复十二项缺陷0.8.1 则把clientRequiredfalse从“可用但危险”升级为编译期错误。对于使用该 emitter 的团队本文逐条解读既可作为版本升级的验收清单也可作为排查生成代码问题的诊断手册——所有结论均可在 packages/http-client-java 的源码与测试中进一步追溯验证。【免费下载链接】typespec项目地址: https://gitcode.com/GitHub_Trending/ty/typespec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
