测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载在 originOpenShift 的 Conformance 测试套件仓库中test/extended/目录承载着一套基于 Ginkgo/Gomega 的功能级扩展测试extended tests。这些测试通过程序化调用ocCLI 和 Kubernetes/OpenShift 客户端来验证构建、镜像、OAuth、路由等核心功能。读完本文你将掌握 extended 测试的运行方式、测试标签规范、目录组织结构、独立测试组启动器的创建方法以及如何用exutil.CLI在 Ginkgo 用例中精确模拟oc命令并断言结果。一、前置条件按照 test/extended/README.md 的说明开发 extended 测试前需要满足两个前提在仓库中同时编译oc与openshift-tests两个命令行工具$ make WHATcmd/openshift-tests设置环境变量KUBECONFIG使其指向你要测试的目标集群$ export KUBECONFIG/path/to/kubeconfigopenshift-tests的入口源码位于 cmd/openshift-tests/openshift-tests.go其子命令实现分散在pkg/cmd/openshift-tests/下例如run、list、monitor、disruption等目录覆盖了运行测试、列出套件、监控测试、扰动测试等场景。二、运行 Extended 测试按全名运行单个测试$ openshift-tests run-test FULL_TEST_NAME查看可用套件列表$ openshift-tests help run具体的测试前置依赖prerequisites会写在各测试的描述文字中运行前先阅读被测用例的 Description。用正则过滤子集运行官方推荐的做法是先把全量测试列表以 dry-run 方式打印出来再用grep -E过滤后通过-f -从标准输入喂给运行器$ openshift-tests run all --dry-run | grep -E REGEX | openshift-tests run -f -这种方式适合在本地只跑与某功能相关的测试子集而不改动 CI 配置。三、测试标签Test Labels规范extended 测试的标签体系与 Kubernetes e2e 测试的标签约定一致README 中引用了 k8s 社区的 e2e-tests 标签说明文档。核心规则如下标签含义与使用条件无标签测试应快速完成5 分钟内、可并行运行且结果一致[Serial]不能与其他测试并行例如占用大量资源或重启节点必须作为独立套件串行运行[Slow]单独或并行运行超过 5 分钟。把慢测试分到独立分区可以让绝大多数测试快速并行跑完。特别注意凡是涉及构建builds的 OpenShift extended 测试都应标记[Slow][Conformance]覆盖集群核心关键功能且不与其它 conformance 测试重复覆盖的用例才算有效。README 给出的正例是“构建能否工作Do builds work”反例是“设置 forcePull 标志后构建能否工作”——后者属于特殊配置不属于 conformance[local]需要访问测试机本地资源例如使用 docker socket的测试原则上 extended 测试应避免访问本地宿主无法避免时才打此标签四、Extended 测试的目录结构扩展测试统一位于 test/extended/ 目录其组织结构为test/extended/util提供 extended 测试共用的辅助函数与工具。它封装了对 OpenShift CLI 的易用接口前文提到的exutil同时提供对 Kubernetes E2E framework 的访问以及跨多个测试用例共享的 OpenShift 辅助逻辑让测试用例保持 DRY。其核心文件 test/extended/util/client.go 定义了CLI类型。test/extended/testdata存放 extended 测试用到的 JSON/YAML 等 fixture 文件当前约 400 个 manifest 文件。test/extended/[images,builds,...]每个 Go 包包含一组相关联的 extended 测试。例如images目录存放验证容器镜像使用场景的用例builds存放构建相关用例。从当前仓库实际目录看除了util与testdata还有apiserver、authentication、authorization、builds、etcd、networking、oauth、operators、router、storage等数十个功能包每个包对应一类被测功能域。五、包Package与测试组Group的区别README 给出的组织原则是每一类功能测试都应当放在自己的 Go 包里但如果你的测试包需要以不同于标准路径的方式专门配置服务端则要在test/extended目录下创建一个与包同名的 launcher 脚本shell 启动器。典型的例子是 LDAP 认证测试你需要先把 OpenShift server 配置成启用 LDAP 认证才能测认证流程。做法是新建测试组ldap并提供 shell 启动器./test/extended/ldap.sh用于以所需配置启动 OpenShift把测试源码放到对应功能包的 Go 目录下例如./test/extended/ldap在顶层 suite 上给你的用例加组前缀var _ g.Describe([ldap] Authenticate using LDAP, func() { # ... })创建新的测试组 Runner如果你的测试需要与其它 extended 用例不同的配置应在test/extended下新建执行脚本并注意用 Ginkgo 的 focus 机制只选中你自己的测试。如果你的测试无法作为默认组的一部分运行务必确保该包不被test/extended的默认入口包含。当前仓库中仍保留了这种 shell runner 的范例——test/extended/cmd.sh。它演示了一个完整的组 runner 生命周期source $(dirname ${BASH_SOURCE})/../../hack/lib/init.sh os::util::environment::setup_time_vars os::build::setup_env # 以默认配置启动 OpenShift server无 registry/router os::util::environment::use_sudo os::cleanup::tmpdir os::util::environment::setup_all_server_vars os::start::configure_server os::start::server export KUBECONFIG${ADMIN_KUBECONFIG} # 注册 junit suite 并执行 oc 命令断言 os::test::junit::declare_suite_start extended/cmd/new-app os::cmd::expect_success oc new-app test/scratchimage~https://github.com/openshift/ruby-hello-world.git --strategydocker ... os::test::junit::declare_suite_end可以看到 launcher 脚本负责环境准备setup_env、use_sudo、服务端配置与启动configure_server、server并用os::test::junit::declare_suite_start/end向 JUnit 报告注册测试套件测试断言则大量使用os::cmd::expect_success_and_text、os::cmd::try_until_text等对oc命令输出做正则验证的封装。Bash 辅助函数README 指出 extended 测试的通用函数位于./hack/util.sh环境设置脚本位于 hack/lib/util/environment.sh主要函数包括函数作用ginkgo_check_extended()检查 Ginkgo 二进制是否已安装compile_extended()将 Go 测试编译为测试二进制test_privileges()校验是否有权限启动 OpenShift serveros::util::environment::setup_all_server_vars()设置 OpenShift server 所需的全部环境变量os::start::configure_server()生成 OpenShift server 的所有配置文件os::start::server()启动 OpenShift master 与 nodeos::start::router()安装 OpenShift 路由服务os::start::registry()安装 OpenShift 容器镜像 registry 服务create_image_streams_extended()为所有 OpenShift 镜像创建 ImageStream从源码结构看os::util::environment::setup_all_server_vars的实际定义在 hack/lib/util/environment.shos::start::configure_server与os::start::server定义在 hack/lib/start.sh——configure_server会生成 master 证书、node 配置与 OpenShift 配置server则启动服务并等待端点可用。编写 launcher 时直接source这些库即可复用整套启动流程。六、CLI 接口在测试中模拟 oc 命令extended 测试的核心能力是通过exutil.CLI包路径 test/extended/util/client.go调用 OpenShift CLI 与 Kubernetes/OpenShift 客户端从而在 Ginkgo 用例中模拟oc命令。顶层 Describe 中创建 CLI 实例要在测试套件中模拟oc命令必须先创建 CLI 实例且应放在顶层 GinkgoDescribe容器中。顶层 Describe 的标签需要同时给出测试所属的 bucket 与简短描述其它全局可访问变量如 fixtures也在此声明package extended import ( g github.com/onsi/ginkgo/v2 o github.com/onsi/gomega ) var _ g.Describe([test bucket] Testing scenario, func() { defer g.GinkgoRecover() var ( oc exutil.NewCLI(test-name) testFixture filepath.Join(testdata, test.json) ) })测试套件应进一步组织为更下层的Describe容器用消息描述测试目标每个下层容器内用单个It承载具体 specIt共享上下文并说明如何达成测试目标var _ g.Describe([default] STI build, func() { defer GinkgoRecover() var ( stiBuildFixture filepath.Join(testdata, test-build.yaml) oc exutil.NewCLI(build-sti, kubeConfigPath()) ) g.Describe(Building from a template, func() { g.It(fmt.Sprintf(should create a image from %q template, filepath.Base(stiBuildFixture)), func() { ... } } }源码层面NewCLI() 会基于给定的 namespace 名称初始化 CLI 及 Kube framework 辅助结构并注册g.BeforeEach(cli.SetupProject)在每条用例前创建项目、g.AfterEach(cli.TeardownProject)在用例后回收项目因此测试用例无需自行管理项目生命周期。从 NewCLIWithoutNamespace() 的实现看底层framework.Framework默认使用ClientQPS: 20、ClientBurst: 50的客户端限流参数execPath固定为ockubeconfig 路径取自KubeConfigPath()——这与前置条件中要求设置KUBECONFIG环境变量相呼应。命令动词与参数Run / Args / Template模拟oc命令时先用Run()指定命令动词get、create、start-build等再用Args()追加参数方法可以自由链式调用oc oc.Run(create)oc oc.Run(create).Args(-f, testFixture)Template()方法可给 CLI 命令附加 Go 模板参数但前提是Run()中指定了get动词oc oc.Run(get).Args(foo).Template({{ .spec }})它等价于命令行执行$ oc get foo -o template --template{{ .spec }}执行与断言Execute / Output / By / Expect执行命令有两种方式Execute()执行命令并返回过程中发生的错误Output()除返回错误外还返回命令输出err : oc.Run(create).Args(-f, testFixture).Execute()buildName, err : oc.Run(start-build).Args(test).Output()用 Ginkgo 的By函数打印下一组命令的意图使测试日志可读g.By(starting a test build) buildName, err : oc.Run(start-build).Args(test).Output()用 Gomega 的Expect语法对错误做断言err oc.Run(create).Args(-f, stiEnvBuildFixture).Execute() o.Expect(err).NotTo(o.HaveOccurred())CLI类型本身的字段设计也印证了这一接口语义从 client.go 中的结构体定义看CLI分别维护verb命令动词、globalArgs、commandArgs、finalArgs最终拼接参数、stdin/stdout/stderr进程标准流以及adminConfigPathkubeconfig等字段Run()/Args()只是往这些字段累积状态真正的进程执行发生在Execute()/Output()调用时源码中对应Run于 L984、Args于 L1032、Output于 L1048、Execute于 L1158 的实现。此外CLI还提供了KubeFramework()访问 Kubernetes framework 助手、SetupProject()/TeardownProject()管理项目以及NewCLIWithFramework()、NewHypershiftManagementCLI()等针对不同场景绑定已有 framework、Hypershift 管理集群的构造方式编写特殊场景测试时可按需选用。七、小结一个新 Extended 测试的完整流程综合以上内容向 origin 仓库提交一个新 extended 测试的标准路径是确认测试归属的功能域将用例放入对应的 Go 包如test/extended/builds/fixture 放入 test/extended/testdata若需要特殊服务端配置在test/extended/下新增同名 launcher 脚本复用hack/lib中的环境与服务启动函数并用 Ginkgo focus 圈定本组用例在顶层Describe中声明 bucket 前缀并创建exutil.NewCLI实例按Run/Args/Template构造命令用Execute/Output执行、o.Expect断言按标签规范决定是否加[Serial]、[Slow]、[Conformance]、[local]标签避免慢测试拖慢并行分区本地用openshift-tests run-test FULL_TEST_NAME或正则过滤子集验证通过后再提交。赞分享测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载相关推荐OrcaSlicer 测试套件实战指南Catch2 测试的组织、编写与构建运行全解析OrcaSlicer 测试套件实战指南Catch2 测试的组织、编写与构建运行全解析 本篇技术指南以 OrcaSlicer 仓库 tests/ 目录下的测试工桌面应用3D渲染图形学Quick 测试组织指南用 Example 与 Example Group 编写结构化测试Quick 测试组织指南用 Example 与 Example Group 编写结构化测试 本文是 QuickSwift / Objective C 行为驱测试开发工具Johnny-Five 扩展测试Extended Tests机制解析时间敏感测试的隔离、编写与运行Johnny Five 扩展测试Extended Tests机制解析时间敏感测试的隔离、编写与运行 导读 Johnny Five 是面向 ArduinoIoT机器人嵌入式上一篇Wayback Machine 扩展上手指南3 步装好找回消失的网页下一篇open-vela packages 快应用示例源码导读Chart图表与Player播放器完整拆解指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/25 16:15:10 · 阅读 1.2k OpenShift Extended 测试实战：在 origin 仓库中编写、运行与结构化组织扩展测试
测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载在 originOpenShift 的 Conformance 测试套件仓库中test/extended/目录承载着一套基于 Ginkgo/Gomega 的功能级扩展测试extended tests。这些测试通过程序化调用ocCLI 和 Kubernetes/OpenShift 客户端来验证构建、镜像、OAuth、路由等核心功能。读完本文你将掌握 extended 测试的运行方式、测试标签规范、目录组织结构、独立测试组启动器的创建方法以及如何用exutil.CLI在 Ginkgo 用例中精确模拟oc命令并断言结果。一、前置条件按照 test/extended/README.md 的说明开发 extended 测试前需要满足两个前提在仓库中同时编译oc与openshift-tests两个命令行工具$ make WHATcmd/openshift-tests设置环境变量KUBECONFIG使其指向你要测试的目标集群$ export KUBECONFIG/path/to/kubeconfigopenshift-tests的入口源码位于 cmd/openshift-tests/openshift-tests.go其子命令实现分散在pkg/cmd/openshift-tests/下例如run、list、monitor、disruption等目录覆盖了运行测试、列出套件、监控测试、扰动测试等场景。二、运行 Extended 测试按全名运行单个测试$ openshift-tests run-test FULL_TEST_NAME查看可用套件列表$ openshift-tests help run具体的测试前置依赖prerequisites会写在各测试的描述文字中运行前先阅读被测用例的 Description。用正则过滤子集运行官方推荐的做法是先把全量测试列表以 dry-run 方式打印出来再用grep -E过滤后通过-f -从标准输入喂给运行器$ openshift-tests run all --dry-run | grep -E REGEX | openshift-tests run -f -这种方式适合在本地只跑与某功能相关的测试子集而不改动 CI 配置。三、测试标签Test Labels规范extended 测试的标签体系与 Kubernetes e2e 测试的标签约定一致README 中引用了 k8s 社区的 e2e-tests 标签说明文档。核心规则如下标签含义与使用条件无标签测试应快速完成5 分钟内、可并行运行且结果一致[Serial]不能与其他测试并行例如占用大量资源或重启节点必须作为独立套件串行运行[Slow]单独或并行运行超过 5 分钟。把慢测试分到独立分区可以让绝大多数测试快速并行跑完。特别注意凡是涉及构建builds的 OpenShift extended 测试都应标记[Slow][Conformance]覆盖集群核心关键功能且不与其它 conformance 测试重复覆盖的用例才算有效。README 给出的正例是“构建能否工作Do builds work”反例是“设置 forcePull 标志后构建能否工作”——后者属于特殊配置不属于 conformance[local]需要访问测试机本地资源例如使用 docker socket的测试原则上 extended 测试应避免访问本地宿主无法避免时才打此标签四、Extended 测试的目录结构扩展测试统一位于 test/extended/ 目录其组织结构为test/extended/util提供 extended 测试共用的辅助函数与工具。它封装了对 OpenShift CLI 的易用接口前文提到的exutil同时提供对 Kubernetes E2E framework 的访问以及跨多个测试用例共享的 OpenShift 辅助逻辑让测试用例保持 DRY。其核心文件 test/extended/util/client.go 定义了CLI类型。test/extended/testdata存放 extended 测试用到的 JSON/YAML 等 fixture 文件当前约 400 个 manifest 文件。test/extended/[images,builds,...]每个 Go 包包含一组相关联的 extended 测试。例如images目录存放验证容器镜像使用场景的用例builds存放构建相关用例。从当前仓库实际目录看除了util与testdata还有apiserver、authentication、authorization、builds、etcd、networking、oauth、operators、router、storage等数十个功能包每个包对应一类被测功能域。五、包Package与测试组Group的区别README 给出的组织原则是每一类功能测试都应当放在自己的 Go 包里但如果你的测试包需要以不同于标准路径的方式专门配置服务端则要在test/extended目录下创建一个与包同名的 launcher 脚本shell 启动器。典型的例子是 LDAP 认证测试你需要先把 OpenShift server 配置成启用 LDAP 认证才能测认证流程。做法是新建测试组ldap并提供 shell 启动器./test/extended/ldap.sh用于以所需配置启动 OpenShift把测试源码放到对应功能包的 Go 目录下例如./test/extended/ldap在顶层 suite 上给你的用例加组前缀var _ g.Describe([ldap] Authenticate using LDAP, func() { # ... })创建新的测试组 Runner如果你的测试需要与其它 extended 用例不同的配置应在test/extended下新建执行脚本并注意用 Ginkgo 的 focus 机制只选中你自己的测试。如果你的测试无法作为默认组的一部分运行务必确保该包不被test/extended的默认入口包含。当前仓库中仍保留了这种 shell runner 的范例——test/extended/cmd.sh。它演示了一个完整的组 runner 生命周期source $(dirname ${BASH_SOURCE})/../../hack/lib/init.sh os::util::environment::setup_time_vars os::build::setup_env # 以默认配置启动 OpenShift server无 registry/router os::util::environment::use_sudo os::cleanup::tmpdir os::util::environment::setup_all_server_vars os::start::configure_server os::start::server export KUBECONFIG${ADMIN_KUBECONFIG} # 注册 junit suite 并执行 oc 命令断言 os::test::junit::declare_suite_start extended/cmd/new-app os::cmd::expect_success oc new-app test/scratchimage~https://github.com/openshift/ruby-hello-world.git --strategydocker ... os::test::junit::declare_suite_end可以看到 launcher 脚本负责环境准备setup_env、use_sudo、服务端配置与启动configure_server、server并用os::test::junit::declare_suite_start/end向 JUnit 报告注册测试套件测试断言则大量使用os::cmd::expect_success_and_text、os::cmd::try_until_text等对oc命令输出做正则验证的封装。Bash 辅助函数README 指出 extended 测试的通用函数位于./hack/util.sh环境设置脚本位于 hack/lib/util/environment.sh主要函数包括函数作用ginkgo_check_extended()检查 Ginkgo 二进制是否已安装compile_extended()将 Go 测试编译为测试二进制test_privileges()校验是否有权限启动 OpenShift serveros::util::environment::setup_all_server_vars()设置 OpenShift server 所需的全部环境变量os::start::configure_server()生成 OpenShift server 的所有配置文件os::start::server()启动 OpenShift master 与 nodeos::start::router()安装 OpenShift 路由服务os::start::registry()安装 OpenShift 容器镜像 registry 服务create_image_streams_extended()为所有 OpenShift 镜像创建 ImageStream从源码结构看os::util::environment::setup_all_server_vars的实际定义在 hack/lib/util/environment.shos::start::configure_server与os::start::server定义在 hack/lib/start.sh——configure_server会生成 master 证书、node 配置与 OpenShift 配置server则启动服务并等待端点可用。编写 launcher 时直接source这些库即可复用整套启动流程。六、CLI 接口在测试中模拟 oc 命令extended 测试的核心能力是通过exutil.CLI包路径 test/extended/util/client.go调用 OpenShift CLI 与 Kubernetes/OpenShift 客户端从而在 Ginkgo 用例中模拟oc命令。顶层 Describe 中创建 CLI 实例要在测试套件中模拟oc命令必须先创建 CLI 实例且应放在顶层 GinkgoDescribe容器中。顶层 Describe 的标签需要同时给出测试所属的 bucket 与简短描述其它全局可访问变量如 fixtures也在此声明package extended import ( g github.com/onsi/ginkgo/v2 o github.com/onsi/gomega ) var _ g.Describe([test bucket] Testing scenario, func() { defer g.GinkgoRecover() var ( oc exutil.NewCLI(test-name) testFixture filepath.Join(testdata, test.json) ) })测试套件应进一步组织为更下层的Describe容器用消息描述测试目标每个下层容器内用单个It承载具体 specIt共享上下文并说明如何达成测试目标var _ g.Describe([default] STI build, func() { defer GinkgoRecover() var ( stiBuildFixture filepath.Join(testdata, test-build.yaml) oc exutil.NewCLI(build-sti, kubeConfigPath()) ) g.Describe(Building from a template, func() { g.It(fmt.Sprintf(should create a image from %q template, filepath.Base(stiBuildFixture)), func() { ... } } }源码层面NewCLI() 会基于给定的 namespace 名称初始化 CLI 及 Kube framework 辅助结构并注册g.BeforeEach(cli.SetupProject)在每条用例前创建项目、g.AfterEach(cli.TeardownProject)在用例后回收项目因此测试用例无需自行管理项目生命周期。从 NewCLIWithoutNamespace() 的实现看底层framework.Framework默认使用ClientQPS: 20、ClientBurst: 50的客户端限流参数execPath固定为ockubeconfig 路径取自KubeConfigPath()——这与前置条件中要求设置KUBECONFIG环境变量相呼应。命令动词与参数Run / Args / Template模拟oc命令时先用Run()指定命令动词get、create、start-build等再用Args()追加参数方法可以自由链式调用oc oc.Run(create)oc oc.Run(create).Args(-f, testFixture)Template()方法可给 CLI 命令附加 Go 模板参数但前提是Run()中指定了get动词oc oc.Run(get).Args(foo).Template({{ .spec }})它等价于命令行执行$ oc get foo -o template --template{{ .spec }}执行与断言Execute / Output / By / Expect执行命令有两种方式Execute()执行命令并返回过程中发生的错误Output()除返回错误外还返回命令输出err : oc.Run(create).Args(-f, testFixture).Execute()buildName, err : oc.Run(start-build).Args(test).Output()用 Ginkgo 的By函数打印下一组命令的意图使测试日志可读g.By(starting a test build) buildName, err : oc.Run(start-build).Args(test).Output()用 Gomega 的Expect语法对错误做断言err oc.Run(create).Args(-f, stiEnvBuildFixture).Execute() o.Expect(err).NotTo(o.HaveOccurred())CLI类型本身的字段设计也印证了这一接口语义从 client.go 中的结构体定义看CLI分别维护verb命令动词、globalArgs、commandArgs、finalArgs最终拼接参数、stdin/stdout/stderr进程标准流以及adminConfigPathkubeconfig等字段Run()/Args()只是往这些字段累积状态真正的进程执行发生在Execute()/Output()调用时源码中对应Run于 L984、Args于 L1032、Output于 L1048、Execute于 L1158 的实现。此外CLI还提供了KubeFramework()访问 Kubernetes framework 助手、SetupProject()/TeardownProject()管理项目以及NewCLIWithFramework()、NewHypershiftManagementCLI()等针对不同场景绑定已有 framework、Hypershift 管理集群的构造方式编写特殊场景测试时可按需选用。七、小结一个新 Extended 测试的完整流程综合以上内容向 origin 仓库提交一个新 extended 测试的标准路径是确认测试归属的功能域将用例放入对应的 Go 包如test/extended/builds/fixture 放入 test/extended/testdata若需要特殊服务端配置在test/extended/下新增同名 launcher 脚本复用hack/lib中的环境与服务启动函数并用 Ginkgo focus 圈定本组用例在顶层Describe中声明 bucket 前缀并创建exutil.NewCLI实例按Run/Args/Template构造命令用Execute/Output执行、o.Expect断言按标签规范决定是否加[Serial]、[Slow]、[Conformance]、[local]标签避免慢测试拖慢并行分区本地用openshift-tests run-test FULL_TEST_NAME或正则过滤子集验证通过后再提交。赞分享测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载相关推荐OrcaSlicer 测试套件实战指南Catch2 测试的组织、编写与构建运行全解析OrcaSlicer 测试套件实战指南Catch2 测试的组织、编写与构建运行全解析 本篇技术指南以 OrcaSlicer 仓库 tests/ 目录下的测试工桌面应用3D渲染图形学Quick 测试组织指南用 Example 与 Example Group 编写结构化测试Quick 测试组织指南用 Example 与 Example Group 编写结构化测试 本文是 QuickSwift / Objective C 行为驱测试开发工具Johnny-Five 扩展测试Extended Tests机制解析时间敏感测试的隔离、编写与运行Johnny Five 扩展测试Extended Tests机制解析时间敏感测试的隔离、编写与运行 导读 Johnny Five 是面向 ArduinoIoT机器人嵌入式上一篇Wayback Machine 扩展上手指南3 步装好找回消失的网页下一篇open-vela packages 快应用示例源码导读Chart图表与Player播放器完整拆解指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考