☰

企业官网建设流程全解析

首页 / 建站日记 / 企业官网建设流程全解析
Nacos Java SDK 集成测试规范（Java SDK IT Spec）深度解析：从场景矩阵到源码实践
2026/9/10 12:25:11 网站建设 项目流程

Nacos Java SDK 集成测试规范（Java SDK IT Spec）深度解析：从场景矩阵到源码实践

【免费下载链接】nacosan easy-to-use dynamic service discovery, configuration and service management platform for building AI cloud native applications.项目地址: https://gitcode.com/GitHub_Trending/na/nacos

导读

本文基于 Nacos 仓库中的 Java SDK 集成测试规范，系统阐述 Nacos Java SDK 公开契约的集成测试模型：它定义了什么算作"SDK 场景覆盖"、变更前如何做影响分析、必须覆盖哪几组场景、测试如何组织与运行，以及 AI Resource Search、Agent、MCP 等新一代能力应如何通过真实 SDK 客户端验证。读完本文，你将掌握test/java-sdk-test模块的设计哲学、五个必测场景组的判定标准、java-sdk-integration-testMaven profile 的正确用法，并能对照仓库中的真实 IT 用例（如ConfigServiceJavaSdkITCase、LockServiceJavaSdkITCase）写出符合规范的高质量 SDK 集成测试。

1. 定位：Java SDK IT 与 HTTP API IT 的分工

Nacos 的集成测试体系由两份互补的规范组成：

  • API 集成测试规范：验证部署后的 HTTP 契约，面向 OpenAPI/适配器层面的接口行为；
  • Java SDK 集成测试规范（本文主体）：验证应用侧看到的类型化 Java SDK 行为，即外部应用通过公开 factory 创建客户端后实际感知到的能力。

两者的边界清晰：HTTP API IT 关心"服务端暴露了什么"，Java SDK IT 关心"客户端承诺了什么"。从仓库源码看，test/java-sdk-test模块的依赖明确只有两个——nacos-client（被测对象）和nacos-maintainer-client（测试夹具，用于发布 AI 资源），见 test/java-sdk-test/pom.xml。

规范开篇即点明目标定位：Java SDK IT 的目标是 SDK 场景覆盖（scenario coverage），不是行覆盖率或分支覆盖率。这决定了用例设计方式——不追求把每个实现分支跑一遍，而是确保每个对外可见的 SDK 行为都有可观测的场景证据。

2. 适用范围：哪些变更必须写 Java SDK IT

规范列出的适用变更范围（原文档第 1 节），可直接对应到仓库中的真实类型：

变更面覆盖对象仓库中的对应类型
公开 interfaceConfigService、NamingService、AiService、A2aService、LockService及 maintainer-client 对应接口api 模块的 ConfigService、lock 模块的 LockService、ai 模块的 AiService
公开 factoryNacosFactory、ConfigFactory、NamingFactory、AiFactory、NacosLockFactoryapi/src/main/java/com/alibaba/nacos/api/config/ConfigFactory.java 等
返回模型SDK 方法返回的 request、response、领域模型ConfigQueryResult、McpServerDetailInfo、AgentCard等
行为契约listener、subscription、本地缓存、redo、factory 初始化、shutdown、异常映射、配置项与默认值JavaSdkBaseITCase中createConfigService的 server status 等待、shutDown注册逻辑

规范同时强调：单元测试仍然需要，但不能替代 Java SDK IT。单元测试负责隔离实现分支（如 AI 能力协商、redo 竞态等确定性场景），而对外可见的 SDK 行为必须由真实客户端 + 真实服务端的集成测试背书。这一点在 JAVA_SDK_IT_COVERAGE.md 中有大量佐证——凡是"共享服务端上难以确定性注入故障"的场景（如getConfig超时、心跳失败、redo 竞态），都被明确标注为"由确定性单元测试覆盖"，而不是硬塞进 IT。

3. SDK 变更规则：先做影响分析，再动代码

规范（第 2 节）要求任何 SDK 契约的增删改弃都必须走五步流程：

  1. 识别影响面：确定受影响的 interface、factory、模型或 listener 路径；
  2. 通读相关实现：阅读公开 API、实现、校验器、传输映射、响应组装、异常映射、生命周期代码及对应 SDK/client 规范；
  3. 形成场景矩阵：覆盖 factory/生命周期、预期功能、边界/校验、listener/subscription、异常/错误处理五类场景；
  4. 同变更集改测试：在同一个变更集中新增、更新或移除test/java-sdk-test用例；
  5. 更新覆盖登记表：维护test/java-sdk-test/JAVA_SDK_IT_COVERAGE.md。

仓库中的 JAVA_SDK_IT_SCENARIOS.md 就是这一流程的产出物模板：它按ConfigService、NamingService、AiService/A2aService、AgentDiscoveryService、Agent Code Publication、LockService分区，每行记录"公开 SDK 面 → 必测场景 → 当前状态（Covered/Partial/Pending/Documented gap）→ 现状说明"。规范还给出了状态语义：一个 SDK API 只要存在未记录的Partial或Pending项，就不能视为完成。

值得注意的兜底条款（原文档第 2 节末尾）：如果完整成功路径在单机 IT 中难以实际执行，测试仍必须覆盖 SDK 参数校验、本地边界行为、受控异常，以及低风险可观测的服务端交互，且被跳过的路径和原因必须写入文档。例如ConfigServiceJavaSdkITCase的 Javadoc 明确记录"timeout 行为被有意排除，因为对共享单机服务端无法确定性触发"，这正是规范"Documented gap"语义的落地。

4. 五大必测场景组：判定标准与真实用例

规范（第 3 节）定义了每个 Java SDK IT 都应覆盖的五组可观测场景。下面结合仓库用例逐一展开。

4.1 Factory 与生命周期

验证 SDK 能通过公开 factory 使用真实 properties 创建、正确处理 server address 与 namespace 默认值、并通过公开 shutdown 释放资源。

仓库基础类 JavaSdkBaseITCase.java 是这一组的集中体现：

protected static final String NACOS_HOST = System.getProperty("nacos.host", "127.0.0.1"); protected static final String NACOS_PORT = System.getProperty("nacos.port", "8848"); protected static final String SERVER_ADDR = NACOS_HOST + ":" + NACOS_PORT; protected ConfigService createConfigService() throws Exception { ConfigService service = ConfigFactory.createConfigService(sdkProperties()); shutdownActions.addFirst(service::shutDown); // 每个实例无条件注册 shutdown waitUntil("config SDK client should connect to server", () -> SDK_STATUS_UP.equals(service.getServerStatus())); return service; }

关键实践：客户端创建后立即在shutdownActions栈中登记shutDown()，由@AfterEach tearDownJavaSdkBase()统一兜底执行——即使断言失败，每个 SDK 实例也必然被关闭（规范第 5 节要求）。AI 客户端由于没有getServerStatus，用一次最小 Search 探测（searchAgents，pageNo=1/pageSize=1）作为就绪探针。

4.2 预期功能（Expected Capability）

验证 SDK 方法完成了承诺的远程或本地行为。规范给出了六种优先采用的可观测流程：

  • 发布后查询（publish-then-query）：发布配置/Agent，再查询确认；
  • 注册后查询（register-then-query）：注册实例/Endpoint，再查询；
  • 订阅后回调（subscribe-then-callback）：订阅后用 CountDownLatch 等待回调；
  • 加锁后解锁（lock-then-unlock）；
  • 发布后加载（release-then-load）；
  • 删除后确认不存在（delete-then-absent）。

规范强调了一个硬性要求：断言必须检查类型化 SDK 返回值、模型字段、回调和远程副作用，不能只判断"没抛异常"。看 ConfigServiceJavaSdkITCase.java 的testPublishQueryCasAndRemoveConfig：

assertTrue(configService.publishConfig(dataId, group, firstContent, ConfigType.TEXT.getType())); waitUntilConfigEquals(configService, dataId, group, firstContent); ConfigQueryResult queryResult = configService.getConfigWithResult(dataId, group, DEFAULT_TIMEOUT_MS); assertEquals(firstContent, queryResult.getContent()); assertNotNull(queryResult.getMd5(), queryResult.toString()); assertFalse(configService.publishConfigCas(dataId, group, "bad-cas-content", "bad-md5", ConfigType.TEXT.getType())); assertEquals(firstContent, configService.getConfig(dataId, group, DEFAULT_TIMEOUT_MS));

每个断言都落在具体结果上：内容一致、md5 非空、错误 md5 的 CAS 被拒绝且服务端状态不变——典型的"副作用可观测"检查。

4.3 边界与校验（Boundary And Validation）

必测项包括：必填参数、可选默认值、非法枚举/类型、namespace/group 默认值、超时行为、异常模型对象、listener 身份要求、重复/幂等调用、资源不存在行为。

ConfigServiceJavaSdkITCase中的testConfigValidationAndDefaultGroupBoundary是教科书式样例：

NacosException missingDataId = assertThrows(NacosException.class, () -> configService.getConfig("", group, DEFAULT_TIMEOUT_MS)); assertEquals(NacosException.CLIENT_INVALID_PARAM, missingDataId.getErrCode(), missingDataId.toString()); // 空 group 视为默认组 DEFAULT_GROUP assertTrue(configService.publishConfig(defaultGroupDataId, "", "default.group.boundary")); waitUntilConfigEquals(configService, defaultGroupDataId, Constants.DEFAULT_GROUP, "default.group.boundary"); // 未知 config type 是兼容性边界，可发布且可查询 assertTrue(configService.publishConfig(invalidTypeDataId, group, "unknown.type.content", "bad-type"));

LockServiceJavaSdkITCase则覆盖了"重复调用幂等"边界：重复 release 返回false、第二个客户端无法获取同一把锁、过期后锁可被他人重新获取（testExpiredLockCanBeAcquiredByAnotherClient），见 LockServiceJavaSdkITCase.java。

4.4 异常与错误处理

验证 SDK 可见的失败产生受控的NacosException或文档化返回值，防止非法输入、资源不存在、远端失败、非法生命周期使用退化成非预期运行时异常。

规范的核心诉求是"把回归抓在 CI 里"：任何把可控失败变成IllegalStateException/NullPointerException的改动都是回归。仓库中的典型验证包括：

  • null listener 在 add/sign/remove 三条路径都被IllegalArgumentException拒绝（testNullConfigListenerIsRejected，异常消息为"listener is null"）；
  • 不支持的锁类型与缺失 key 映射为受控NacosException（testInvalidLockInputThrowsControlledException）；
  • 缺失配置的getConfigWithResult返回空形状的 Result 对象（content/md5/configType 均为 null），而非抛异常或返回 null——这是"文档化返回值"的典型；
  • AI 场景中 gRPC 未实现的 Skill/AgentSpec 路径返回受控SERVER_NOT_IMPLEMENTED错误（见AiTransportResourceMatrixJavaSdkITCase）。

4.5 Listener 与订阅行为

对 listener API 验证：适用场景下的初始查询行为、可观测变更触发回调、unsubscribe/remove 行为与清理。等待必须有边界，且提供清晰断言信息。

ConfigServiceJavaSdkITCase的testGetConfigAndSignListenerReceivesUpdates展示了标准写法：

CountDownLatch latch = new CountDownLatch(1); AtomicReference<String> received = new AtomicReference<>(); Listener listener = new Listener() { @Override public Executor getExecutor() { return null; } @Override public void receiveConfigInfo(String configInfo) { if (secondContent.equals(configInfo)) { received.set(configInfo); latch.countDown(); } } }; ... assertEquals(firstContent, configService.getConfigAndSignListener(dataId, group, DEFAULT_TIMEOUT_MS, listener)); assertTrue(configService.publishConfig(dataId, group, secondContent)); assertTrue(latch.await(10, TimeUnit.SECONDS), "listener should receive updated config");

要点：回调里按目标内容过滤（避免把初始值误判为更新）、CountDownLatch.await(10s)有界等待、removeListener后发布变更并用assertFalse(latch.await(2, TimeUnit.SECONDS))证明回调停止（testRemoveListenerStopsLaterCallbacks）。AI 侧的AiServiceJavaSdkITCase还验证了 MCP/A2A 的 current-value 回调与 missing-resource nullable 订阅形状。

5. 测试组织：包结构与基类抽象

规范（第 4 节）要求 Java SDK IT 放在固定包下：

  • com.alibaba.nacos.test.sdk.config
  • com.alibaba.nacos.test.sdk.naming
  • com.alibaba.nacos.test.sdk.ai
  • com.alibaba.nacos.test.sdk.lock
  • 新增 maintainer SDK IT 时使用com.alibaba.nacos.test.sdk.maintainer.<domain>

仓库实际结构完全遵循该约定：test/java-sdk-test/src/test/java/com/alibaba/nacos/test/sdk/ 下含JavaSdkBaseITCase基础类与四个业务子包，共 8 个测试类（ConfigServiceJavaSdkITCase、NamingServiceJavaSdkITCase、AiServiceJavaSdkITCase、AgentDiscoveryServiceJavaSdkITCase、AgentPublishJavaSdkITCase、AiTransportResourceMatrixJavaSdkITCase、LockServiceJavaSdkITCase）。

规范建议"一个公开 SDK interface 或一组强关联 API family 对应一个测试类"，并把共享的客户端构造、清理、有界等待、随机资源名、shutdown 逻辑抽象到基础类。JavaSdkBaseITCase正是这样做的：

  • 统一sdkProperties()：SERVER_ADDR即nacos.host:nacos.port，默认127.0.0.1:8848；
  • 随机资源名工具：randomDataId("lifecycle")生成java-sdk-it-lifecycle-<12位uuid>.data，randomServiceName、randomGroup、randomPort同理，保证并行与重复运行时资源隔离；
  • 双栈清理：cleanupActions（资源清理，如removeConfig）与shutdownActions（客户端 shutdown）在@AfterEach中按 LIFO 顺序执行，且清理时吞掉NOT_FOUND/RESOURCE_NOT_FOUND这类可忽略异常；
  • waitUntil(reason, condition)有界轮询：10 秒 deadline、500ms 间隔，失败时携带最后一次异常信息fail(reason + ", last failure: ...")。

6. 运行规则：JUnit 5 + Failsafe 的硬约束

规范（第 5 节）给出七条运行硬规则，全部可在仓库中找到对应实现：

  1. JUnit 5 + Failsafe：test/java-sdk-test/pom.xml中 parent 为nacos-test，测试框架为 JUnit 5，maven-failsafe-plugin绑定integration-test与verify两个 goal；
  2. 禁止@SpringBootTest/SpringExtension，禁止在测试类内启动 Nacos：IT 假设单机 Nacos 已启动，SDK 以外部应用身份连接；
  3. 读取nacos.host和nacos.port，默认127.0.0.1:8848：见JavaSdkBaseITCase第 47-51 行，同时 pom 的systemPropertyVariables会注入这两个属性；
  4. 通过公开 factory 创建真实客户端：ConfigFactory.createConfigService、NamingFactory.createNamingService、AiFactory.createAiService、NacosLockFactory.createLockService；
  5. 生成隔离资源名：前述随机命名工具；
  6. 清理创建的 config/naming/AI/lock 资源：addCleanup注册表；
  7. 对异步服务端效果使用有界重试：waitUntil机制贯穿所有用例。

此外，pom 中还暴露了三个可调系统属性（均为测试隔离设计）：

  • nacos.client.json.adapter：默认auto，配合jackson3-sdk-testprofile 切换为jackson3，用于验证默认 JSON Adapter 与 Jackson 3 Adapter 的行为等价（对应规范第 9 节）；
  • nacos.agent.it.server.publication.capacity：服务端发布软水位（默认 100）；
  • nacos.agent.it.client.publication.capacity/nacos.agent.it.client.subscription.capacity：客户端发布/订阅容量（默认 3），用于验证本地容量与槽位复用。

7. 场景文档：Javadoc 与覆盖登记表

规范（第 6 节）要求：每个 SDK IT 类都必须包含简洁的Scenario coverageJavadoc；矩阵较大时更新 JAVA_SDK_IT_COVERAGE.md。

仓库中的做法是"类内 Javadoc + 仓库级登记表 + 详细矩阵"三层结构：

  • 类级 Javadoc：ConfigServiceJavaSdkITCase的类注释用<ul>逐条列出 Expected capability / Boundary-validation / Error handling / Listener / Filter-type 五组覆盖点，并链接到场景矩阵文档；
  • 覆盖登记表：JAVA_SDK_IT_COVERAGE.md 以表格登记每个 interface 的状态（Covered/Partial）、场景覆盖摘要与 Known gaps，并声明Partial表示"有代表性覆盖但不可视为完整场景覆盖"；
  • 详细矩阵：JAVA_SDK_IT_SCENARIOS.md 按接口逐行记录必测场景与现状；Agent Discovery 与 Agent Publish 的扩展矩阵分别在 AGENT_DISCOVERY_SDK_IT_SCENARIOS.md 与 AGENT_PUBLISH_SDK_IT_SCENARIOS.md。

登记表还明确列出"待补充的 SDK 面"：废弃的NamingMaintainService与 maintainer-client SDK 接口（后者在 test/maintainer-sdk-test 单独跟踪），并给出 Recommended Next Test Batches（如确认 Naming fuzzy-watch delete 事件契约、为 Prompt/Skill/AgentSpec 增加功能级 IT）。

8. 验证命令：静态检查与完整 verify

规范（第 7 节）给出两级验证命令，从轻到重：

变更后必跑的基础验证：

mvn -pl test/java-sdk-test spotless:check mvn -pl test/java-sdk-test -DskipTests test-compile

单机 Nacos 可用时的完整验证：

mvn -pl test/java-sdk-test -Pjava-sdk-integration-test -DskipTests=false verify

规范特别强调了 profile 隔离的重要性：Java SDK IT 必须使用独立的java-sdk-integration-testprofile；通用integration-testprofile 保留给 HTTP API IT 工作流，不能意外运行依赖 SDK gRPC 连接就绪或可选服务端能力的 SDK 测试。从 test/java-sdk-test/pom.xml 可以看到，Failsafe 插件及其系统属性注入全部封装在java-sdk-integration-testprofile 内，默认构建不会执行这些用例——这正是防止 CI 串扰的设计。

9. AI Resource Search 与 Agent 场景矩阵

规范（第 8 节）规定公共 AI SDK Search 或 Agent 行为变更时，Java SDK IT 至少覆盖六类场景：

  1. 真实 SDK Client 的检索能力：Agent 单条件、组合 predicate、numbered page、默认 namespace 查询；
  2. 传输等价性：HTTP 与 gRPC 在相同事实与传输选择下返回等价目录；
  3. 发布状态收敛：Agent publish/online/offline/latest 切换后的有界收敛，且 Endpoint 操作只改变 Discover 结果；
  4. 候选资格一致：通用单类型 Search 与 Agent、AgentSpec、Skill、Prompt、MCP 资源专用 Search 的候选资格一致；
  5. 传输协商：Client transportAUTO/HTTP/GRPC可用时保持同一 Search 契约，协商不支持时返回受控异常；
  6. 副作用隔离：SDK shutdown、重连和 redo 不重复写目录索引，也不把 Runtime Endpoint 带入 Search 结果。

仓库中的落地证据非常充分：

  • AgentDiscoveryServiceJavaSdkITCase.java 覆盖了AUTO在 gRPC 可用时的协商连接、AUTO在 gRPC 永不离开STARTING时的 HTTP 立即路由、显式GRPC无回退等传输矩阵；
  • 定向 IT 会真实重启单机服务端，在同一 SDK 进程内验证连接失败、重连、协议无关的 gRPC publication redo 与 HTTP50404publication replay；
  • 规范同时划定边界：ARD Artifact 的协议一致性继续由 OpenAPI/适配器 IT 覆盖，Java SDK IT 只通过公开 SDK 合同验证可观察目录与 Discover 行为——这再次呼应了第 1 节的分工原则。

10. MCP 兼容与 Runtime Endpoint 场景矩阵

规范（第 9 节）规定 MCP Storage 路由或生命周期托管变化时的必测项，这是全文最细化的矩阵：

  1. 版本生命周期：真实AiService发布新 MCP Resource/Version，保留历史 ID 响应，支持按精确 Version 与 Latest 查询，并观察到与之前相同的 Enable 与 Published Serving 内容；
  2. 历史冲突隔离：历史精确 Version 的 Conflict/Overwrite 行为只存在于兼容 Facade，不影响标准生命周期写入；
  3. 订阅语义：subscribeMcpServer的初始投递、完整结果变化回调、Unsubscribe、重新 Subscribe、Shutdown 清理，且不建立直接 Naming Subscription；
  4. Runtime Endpoint 韧性：当前按 Version 划分的 Register/Deregister、Service/Cluster/Metadata 兼容性，断连、重连、Redo 恢复同一份防御性 Publication Snapshot——不重复 Instance，也不丢失其他 MCP Publication；
  5. gRPC 字段契约：Java Client 继续使用mcpName，不填充 Dormant 顶层 gRPCmcpId，同时 Active Model、Event、Response ID 字段保持当前值；
  6. 生命周期隔离：生命周期对账和管理切换不新增 Runtime Publication、Naming Layout、能力协商或公开AiServiceInterface 行为；
  7. JSON 适配器等价：默认 JSON Adapter 与 Jackson 3 Adapter 在使用当前 Request Fixture 和 Response Model 时行为等价（对应 pom 中的jackson3-sdk-testprofile）。

对应的AiServiceJavaSdkITCase与AiTransportResourceMatrixJavaSdkITCase还验证了 MCP 在 HTTP 模式下惰性启动共享 gRPC 客户端、Skill ZIP 下载在所有模式下保持 HTTP、Skill/AgentSpec 的 gRPC 订阅路径返回受控SERVER_NOT_IMPLEMENTED等当前路由兼容性契约。

规范同时明确排除项：无 Version 的 Runtime Service、显式 Transport List、MCP Version Range、Client HTTP 对齐和心跳续约，在独立设计批准前不属于该矩阵——这保证了测试范围与已批准契约严格对齐，避免测试先行于设计。

11. 给 SDK 贡献者的实践清单

综合全文，向 Nacos Java SDK 提交变更时的最小实践清单如下：

  1. 变更前：对照规范第 2 节的五步流程完成影响分析与场景矩阵；
  2. 测试落位：用例放在com.alibaba.nacos.test.sdk.*对应包，一个 interface 一个测试类，继承JavaSdkBaseITCase复用基类能力；
  3. 断言标准：检查类型化返回值、模型字段、回调与远程副作用，而非"不抛异常"；
  4. 生命周期：所有创建的 SDK 实例与资源注册到 cleanup/shutdown 栈，保证断言失败也清理；
  5. 等待有界：异步效果统一走waitUntil有界重试或CountDownLatch.await(超时)；
  6. 文档同步：更新类级Scenario coverageJavadoc 与 JAVA_SDK_IT_COVERAGE.md，被跳过的分支必须给出理由；
  7. 验证命令：先跑spotless:check与test-compile，单机服务端就绪后执行-Pjava-sdk-integration-test verify。

遵循这套规范，SDK 变更就能同时获得"真实客户端可见行为"的集成证据与"确定性分支行为"的单元证据，两者互补、缺一不可——这正是 Nacos Java SDK 契约质量得以长期保持的测试根基。

【免费下载链接】nacosan easy-to-use dynamic service discovery, configuration and service management platform for building AI cloud native applications.项目地址: https://gitcode.com/GitHub_Trending/na/nacos

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

标签： 网站建设 企业官网 项目流程 UI设计 前端开发

热门文章

文章分类

标签云

网站建设 响应式设计 用户体验 SEO优化 前端开发 小程序 电商平台 性能优化

相关文章

您可能感兴趣的其他内容

恶意软件沙箱逃逸技术解析：T1497 检测指标体系与 Cuckoo/AnyRun 行为报告自动化分析实战（Anthropic-Cybersecurity-Skills）
2026/9/10 12:25:04 网站建设

恶意软件沙箱逃逸技术解析：T1497 检测指标体系与 Cuckoo/AnyRun 行为报告自动化分析实战（Anthropic-Cybersecurity-Skills）

恶意软件沙箱逃逸技术解析&#xff1a;T1497 检测指标体系与 Cuckoo/AnyRun 行为报告自动化分析实战&#xff08;Anthropic-Cybersecurity-Skills&#xff09; 【免费下载链接】Anthropic-Cybersecurity-Skills 817 structured cybersecurity skills for AI agents Mapped to …...

阅读更多 →
HyperFrames v0.7.55 版本解读：Studio 时间线碰撞放置模型与渲染捕获正确性修复
2026/9/10 12:23:42 网站建设

HyperFrames v0.7.55 版本解读：Studio 时间线碰撞放置模型与渲染捕获正确性修复

HyperFrames v0.7.55 版本解读&#xff1a;Studio 时间线碰撞放置模型与渲染捕获正确性修复 【免费下载链接】hyperframes Write HTML. Render video. Built for agents. 项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes 本篇基于 v0.7.55 发布说明&…...

阅读更多 →
LlamaIndex LegacyOfficeReader 实战：借助 Apache Tika 解析 Word 97（.doc）等旧版 Office 文档
2026/9/10 12:22:50 网站建设

LlamaIndex LegacyOfficeReader 实战：借助 Apache Tika 解析 Word 97（.doc）等旧版 Office 文档

LlamaIndex LegacyOfficeReader 实战&#xff1a;借助 Apache Tika 解析 Word 97&#xff08;.doc&#xff09;等旧版 Office 文档 【免费下载链接】llama_index LlamaIndex is the leading document agent and OCR platform 项目地址: https://gitcode.com/GitHub_Trending/…...

阅读更多 →

需要专业的网站建设服务？

联系我们获取免费的网站建设咨询和方案报价，让我们帮助您实现业务目标

立即咨询