etcd Robustness 测试框架深度解析用一致性模型验证 KV 与 Watch 的故障场景正确性【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcdetcd 的 Robustness健壮性/鲁棒性测试是服务于分布式 KV 最核心正确性的一整套端到端故障注入与验证框架它在真实 etcd 集群上制造节点崩溃、网络分区、磁盘持久化丢失等故障同时记录全部客户端操作历史再把这些历史拿去与一个简化的一致性模型对拍从而检验 etcd 是否严格兑现了 KV API guarantees 与 Watch API guarantees。阅读本文后你将掌握这套框架的架构与五步测试流程、make test-robustness系列命令的完整用法、如何复现历史上真实正确性缺陷如 #14370、#15271、如何把失败报告拷回本地重新评估以及如何借助history.html可视化逐条分析线性化与 Watch 违约问题。本文主体源自仓库中的 tests/robustness/README.md并结合该目录下的源码tests/robustness、tests/antithesis进行展开印证。该测试框架归属 tests 独立 Go moduletests/go.mod运行入口由根 Makefile 引入的 tests/robustness/Makefile 提供。一、Robustness 测试的定位给分布式共识系统上强度etcd 是使用 Raft 达成共识的分布式 KV 存储它的承诺不仅是数据能写进去更关键的是在进程崩溃、网络抖动、磁盘异常等现实故障面前依然守住两类 API 保证KV API 保证包括修订号revision单调递增、写操作的严格可串行化strict serializable、读请求的可线性化等Watch API 保证事件按 revision 有序Ordered、同一事件不会重复出现Unique、不会丢事件子序列Reliable、可断点续传Resumable、同一 revision 的批量更新不会被拆散Atomic等。Robustness 测试的目的就是在广泛的条件与故障组合下严格验证 etcd 是否仍然维持上述保证。它的核心思想不是写死断言而是把集群实际行为与一个期望模型做对比。从 scenarios.go 看它至少覆盖三类可变维度不同的 etcd 集群形态单节点与三节点集群、Peer 间启用 TLS、Peer 代理proxy、混合版本部署当前版本与上一发行版混布含不同 leader 版本组合、带 LazyFS 故障磁盘的场景不同的客户端流量类型纯 Put、Put/Delete/Lease租约授予与回收、事务TXN与 Range 读取、模拟 Kubernetes 的 create/delete 语义Kubernetes 资源存取模式以及不同 QPS/并发档位不同的故障注入kill 进程、Raft/存储/压缩/去碎片等关键路径上的 gofail panic、网络黑洞blackhole、延迟delay、丢包drop。需要说明的是这套 Robustness 框架定位在故障下的正确性验证与常规 e2e 功能测试验证功能是否可用互补它只负责回答坏了之后数据语义还对不对。二、Robustness 与 Antithesis确定性仿真测试的关系仓库中还有一个tests/antithesis目录README 里特别解释了二者的关系Antithesis 是把 Robustness 测试放进它自己的确定性仿真测试deterministic simulation testingDST环境与故障注入框架里去跑而不是一个独立的新测试套件。Robustness 框架产出的场景定义、校验器与报告逻辑在两者之间是共用的集成细节可继续阅读仓库中的 tests/antithesis含 antithesis 客户端/server 补丁与Makefile。从战绩表可以看到Discovered by 一栏同时出现了 Robustness 与 Antithesis例如 2025 年 6 月 #20221 的watch on future revision returns old events以及 #20271、#20418 均由 Antithesis 环境首先捕获说明在确定性仿真里重复投掷故障可以覆盖纯概率性混沌难以命中的时序窗口。三、战绩记录Robustness 框架发现/守护过的正确性缺陷README 用一张表格沉淀了框架自 2022 年以来发现或持续回归守护的正确性/一致性问题。这张表既是能力证明也是回归测试不得丢失的资产清单。每行的Reproduction Script给出了一个可执行的复现目标多数形如make test-robustness-issueNNNNN由 tests/robustness/Makefile 提供这些目标会自动构建带 failpoint 的对应历史版本二进制例如 v3.5.2/v3.5.4/v3.5.7/v3.5.12 等必要时还会先对源码打补丁见 tests/robustness/patches 下的beforeSendWatchResponse、compactBeforeSetFinishedCompact以恢复缺陷当时的代码状态。语义提醒这些复现目标是测试失败即缺陷复现成功——Makefile 中... test-robustness echo Failed to reproduce || echo Successful reproduction恰好说明了这一点只有健壮性测试报错如Linearization illegal、Broke watch guarantee才意味着历史 bug 被重新触发。正确性/一致性问题报告时间引入版本发现者最近复现 commit复现脚本高负载下崩溃导致 revision 不一致#137662022-03v3.5用户负载不足以触发make test-robustness-issue13766单节点集群崩溃丢失一次写入#143702022-08v3.4 或更早用户a4387592026-01-03make test-robustness-issue14370启用鉴权auth可能引发不一致#145712022-10v3.4 或更早用户鉴权路径未覆盖—去碎片defrag过程中崩溃致 revision 不一致#146852022-11v3.5Robustness覆盖 defrag 后a4387592026-01-03make test-robustness-issue14685Watch 进度通知与数据流不同步#152202023-01v3.4 或更早用户a4387592026-01-03make test-robustness-issue15220网络分区后 Watch 时间回退#152712023-02v3.4 或更早Robustness覆盖网络分区后—make test-robustness-issue15271TXN 缓存缺陷导致 Watch 事件重复#172472024-01mainRobustness防止 main 回归——流饥饿期间丢失 Watch 事件#175292024-03v3.4 或更早用户c272ade2025-05-30make test-robustness-issue17529压缩compaction崩溃致 revision 递减#177802024-04v3.4 或更早Robustness覆盖 compaction 后——删除路径压缩时 Watch 丢一个事件#180892024-05v3.4 或更早Robustness覆盖 compaction 后a4387592026-01-03make test-robustness-issue18089短时间内收到两个快照导致 panic#180552024-05v3.4 或更早Robustness——TXN 中读取已压缩 revision 不一致#186672024-10v3.4 或更早用户——在与 compaction 同一 revision 上打开的 Watch 丢失 delete 事件#191792025-01v3.4 或更早Robustness覆盖 compaction 后—make test-robustness-issue19179对未来 revision 的 Watch 返回通知#202212025-06v3.4 或更早Robustness覆盖多成员连接后—make test-robustness-issue20221对未来 revision 的 Watch 返回旧事件#202212025-06v3.4 或更早Antithesis覆盖多成员连接后——db 页大小异常 panic#202712025-07v3.4 或更早Antithesis——进程被暂停引发的过期读#204182025-07v3.5.0 与 v3.4.20Antithesis——3.1 大型改动期间如何守住缺陷可复现能力框架迭代越深越可能顺手修掉某个曾捕获 bug 的触发条件。README 明确给出了维护纪律——由于这些已知问题许多带有专属复现命令因此最新版框架必须仍然能复现旧缺陷Last reproduction commit一列就是人工维护的证据。最佳实践五步建立基线Establish Baseline动手做大改动前先跑一遍战绩表中所有可复现用例验证可复现Verify Reproducibility改动完成后再次验证此前能复现的 bug 依旧能被检测出来更新跟踪记录Update Tracking刷新最近复现 commit列的 commit 哈希及其创建日期证明新框架版本依然有效更新命令Update Commands若改动影响了测试执行路径同步更新对应的复现命令把关完成度Gate Completion在所有回归用例仍能咬住目标 bug 之前不要认为这次改动已经完成。这保证了测试框架的改进不会无意中削弱我们发现已知故障模式的能力。四、测试原理五步走把真实历史与模型对拍Robustness 测试的工作方式是把 etcd 集群的真实行为与一个简化期望模型做比较compare … against a simplified model of its expected behavior。整体五步流程为创建集群按指定配置拉起全新的 etcd 集群注入流量与故障向集群持续施加客户端流量同时在恰当的时机注入故障收集历史完整记录所有客户端操作的发起、返回、结果校验把收集到的历史交给 etcd 模型与一组 validator 校验一致性生成报告一旦发现失败产出包含客户端操作与 etcd 数据目录的详细报告便于诊断。4.1 源码入口测试是怎么组织起来的框架主体在 tests/robustness/main_test.go定义了两个顶层测试TestRobustnessExploratory对scenarios.Exploratory(t)返回的每个探索式场景随机挑选一个当前可用的 failpoint 再执行failpoint.PickRandomTestRobustnessRegression对scenarios.Regression(t)返回的每个历史缺陷回归场景执行例如TestRobustnessRegression/Issue14370、/Issue15271等这正是make test-robustness-issue*目标里--runTestRobustnessRegression/IssueNNNNN所匹配的测试名。testRobustness是核心编排函数其代码路径main_test.go印证了上述五步创建报告对象report.NewTestReport并注册defer r.Finalize(...)以保证即使 panic 也能保存数据运行场景runScenario三个 goroutine 并行执行——故障注入等待WaitBeforeFailpoint±抖动后触发再等WaitAfterFailpoint、KV/事务流量模拟traffic.SimulateTraffic并把全集群最大 revision 送入 channel、全集群 Watch 事件采集CollectClusterWatchEvents结束后做一次 HashKV 一致性终检CheckEndOfTestHashKV保存 etcd 数据目录r.SaveEtcdData调用校验层validate.ValidateAndReturnVisualize并把校验成功时的线性化可视化函数挂到报告上最后落盘history.html。testResultsDirectory显示报告默认落在/tmp/下可用RESULTS_DIR覆盖目录名形如TestRobustnessRegression_Issue14370/UnixNano。4.2 校验层线性化优先其余校验随后validate/validate.go 中的ValidateAndReturnVisualize严格遵循线性化失败则跳过其余校验的原则因为它们必然也失败只会淹没日志。其判定顺序为前置假设Assumptions校验validateEmptyDatabaseAtStart模型要求空库启动因此必须保证有revision 1的读与validateNonConcurrentClientRequests同一客户端串行无并发请求这是 porcupine 线性化检查的前提线性化Linearization借助porcupine库对可线性化操作做历史搜索。为支持该检查写失败请求的返回时间会被置为MaxInt64因为不知道它何时真正生效。若客户端没收到响应但写确实持久化了还会用 WAL 回放出的 persisted requests 对历史做补全patchLinearizableOperationsWatch 校验在确定性模型回放model.NewReplay(persistedRequests)的基础上逐客户端核验 Watch 保证可串行化Serializable仅针对带指定 revision 的 Range陈旧读等特定请求。模型本身在 model/deterministic.goDeterministicModel维护EtcdStaterevision、compactRevision、key→ValueRevision、lease 列表等用Step/apply模拟 etcd 对每类请求的语义响应再与真实响应做Matchmodel/types.go 中MaybeEtcdResponse对客户端观察到、已持久化未观察到、带 revision 的持久化、错误响应四种状态做了建模。请求历史通过 model/history.go 的AppendableHistory以porcupine.Operation形式按单调时钟追加为避免并发请求共流失败写会切换新的 stream ID。Watch 校验器清单可以对照 validate/watch.go 中的各错误定义逐条理解Ordered、Unique、Atomic、Bookmarkable、Reliable、Resumable外加事件prevValue/IsCreate/过滤条件是否正确——这正是文章开头所说 Watch API guarantees 的可执行化。4.3 探索式场景它都在随机什么从 scenarios/scenarios.go 可以看出探索式Exploratory测试的随机面设计集群规模 1/3、心跳/选举超时三档、混合版本60% 全当前版本 多档 2-1 分账且 leader 版本可变的组合、快照阈值与压缩批大小随机其中刻意设置很小的 compaction batch limit 以便触发多批压缩的 failpoint、每 100ms 的进度通知间隔以及检测到 LazyFS 可用时为低 QPS 场景追加LazyFS变体并关闭压缩。TRACING_SERVER_ADDR环境变量存在时会追加分布式追踪选项对应后文 OpenTelemetry 导出。流量画像有EtcdHighTraffic、EtcdTrafficDeleteLeases、KubernetesHighTraffic、KubernetesLowTraffic四档。故障注入库定义在 failpointgoPanic 系列如raftBeforeSave、defragBeforeCopy、compactBeforeSetFinishedCompact等gofail.go网络系列blackholePeerNetwork/BlackholeUntilSnapshot/delayPeerNetwork/dropPeerNetworknetwork.go后者通过 Peer proxy 对成员做双向黑盒/延迟/丢包必要时等待该成员落后足够条目触发快照追赶以及直接kill进程的KillFailpointkill.go。每个 failpoint 都实现Available(...)判定当前集群是否支持Inject前后还会做 gRPC 健康检查failpoint.go确保故障是注入到健康集群的。值得一提的是 LazyFS 场景下 kill 之后会执行ClearCache丢弃未 fsync 的数据从而真实模拟断电丢页级别的持久化丢失。五、关键概念一致性术语、etcd 保证与 Kubernetes 契约读懂这些测试需要先对齐一批分布式系统术语README 中也有系统化定义共识Consensus分布式系统各节点对单一数据值达成一致的过程etcd 采用 Raft 算法严格一致 vs 最终一致严格一致指更新后所有组件立刻看到相同数据最终一致指组件可能暂时看到不同视图、但最终收敛单对象一致性模型顺序一致性Sequential——操作看似按某个与各进程内顺序相符的全序发生可线性化Linearizable——最强的单对象模型操作瞬间发生且与实时顺序一致事务性一致性模型可串行化Serializable——事务按某个全序原子执行、互不交错是作用于全系统而非单对象的多对象属性严格可串行化Strict Serializable——最强的事务模型把串行化的全序与可线性化的实时约束叠加。etcd 对外承诺的组合是KV 操作为严格可串行化Watch 为最终一致。Robustness 校验器正是照此实现KV 历史走 porcupine 线性化可线性化即严格可串行化在单对象上的投影Watch 历史则按最终一致但事件保序、不重、不丢、可续的语义校验。关于 Kubernetes 集成README 引用了一个隐式 Kubernetes-etcd 契约Kubernetes 用 etcd 存储集群状态其ResourceVersion字符串正是对应 etcd 的 revision同时 Kubernetes 把每种资源类型视为完全独立的实体允许把每种资源类型分片到独立的 etcd 集群。因此 tests 中单独提供 Kubernetes 流量模型traffic/kubernetes.go来贴近这类真实调用形态例如使用WithPrevKV()的 Watch。六、本地运行构建 failpoint 版本并执行6.1 用 gofail 构建带故障注入点的 etcdRobustness 依赖 gofail 在 etcd 关键路径上植入的可触发故障点因此必须先构建带 failpoint 的二进制make gofail-enable make build make gofail-disable三个目标的底层行为可以对照 tests/robustness/Makefilegofail-enable先用go install go.etcd.io/gofail版本安装 gofail 工具版本取自tools/mod的 go.mod再对server/etcdserver、server/lease、server/storage/backend、server/storage/mvcc、server/storage/wal、server/etcdserver/api/v3rpc、membership、rafthttp等目录执行gofail enable并把 gofail 依赖注入 server/etcdutl/etcdctl/tests 各 modulegofail-disable执行相反的gofail disable并go mod tidy清理。注意make build后通常需要先用make gofail-disable恢复普通源码避免把 gofail 标记带进后续常规构建。6.2 跑通测试套件make test-robustness该目标定义在根 Makefile等价于PASSESrobustness ./scripts/test.sh $(GO_TEST_FLAGS)。还支持按需透传环境变量环境变量作用说明GO_TEST_FLAGS传给go test的额外参数README 建议多次运行并开启 failfastGO_TEST_FLAGS--count100 --failfastEXPECT_DEBUGtrue输出集群日志便于本地排查RESULTS_DIR报告保存位置默认/tmp/见 main_test.go 中testResultsDirectoryPERSIST_RESULTS无论成败都持久化报告默认只有失败/panic 时保留报告见 report/report.go 中Finalizekeep : tFailed || panicked || persistResultsTRACING_SERVER_ADDR导出 OpenTelemetry trace 的目标地址例如localhost:4317供分布式追踪收集器消费想对历史缺陷做定向回归可运行仓库预置目标例如make test-robustness-issue14370 # 单节点崩溃丢写 make test-robustness-issue15271 # 网络分区后 Watch 回退 make test-robustness-issue20221 # 多成员连接下对未来 revision 的 Watch这些目标见 tests/robustness/Makefile 中test-robustness-issue*会自动 clone 对应 tag如 v3.5.4以FAILPOINTStrue ./build或打补丁方式构建带故障点的二进制到/tmp/etcd-vX.Y.Z-failpoints/bin随后执行--runTestRobustnessRegression/IssueNNNNN --count 100 --failfast。若需要同时回归 main 分支与上一发行分支的跨版本滚动验证升级路径上的正确性可用make test-robustness-main、make test-robustness-release-3.7、test-robustness-release-3.6、test-robustness-release-3.5、test-robustness-release-3.4等目标它们把新旧两个版本的 failpoint 二进制分别传给--bin-dir与--bin-last-release。七、重新评估已有报告修复模型后回放旧失败Robustness 的校验逻辑模型、validator一直在演进——模型自身的缺陷可能造成假阳性。因此当模型被修复后能否用新代码重新评估旧报告就很重要。README 先给出一条重要提示报告格式并不稳定不保证所有旧报告都能用最新版本重新评估。操作步骤注意默认只在失败时产出报告定位报告位置本地运行检索日志中Saving robustness test report一行的path字段例如logger.go:146: 2024-04-08T09:45:27.7340200 INFO Saving robustness test report {path: /tmp/TestRobustnessExploratory_Etcd_HighTraffic_ClusterOfSize1}CI 远程运行进入 Prow 任务页下载构建产物artifacts/results.zip并解压到本地。归档内每个以TestRobustness为前缀的目录都对应一份 robustness 测试报告通常体积最大的目录对应失败的那个场景如果不确定可结合测试日志判断。复制报告目录到testdatatestdata可同时存放多份报告目录 tests/robustness/testdata目录名只要唯一即可例如某history.html的路径可为$REPO_ROOT/tests/robustness/testdata/v3.5_failure_24_April/history.html运行回归校验make test-robustness-reports该目标会执行go test ./robustness/validate -v --count 1 --run TestDataReports把testdata下所有报告重新喂给最新版校验器。八、失败报告分析目录结构与会话级证据当一次 robustness 运行失败或显式要求持久化后报告目录被整理成如下层级对照 report/report.go 的落盘逻辑与 README 定义server-*——各 etcd server 的数据目录用于核对磁盘/内存损坏member/wal预写日志WAL目录可用tools下的 etcd-dump-logs 命令行工具分析member/snap快照目录内含 bbolt 数据库文件db可用 etcd-dump-db 分析client-*——各客户端请求/响应 JSON 转储watch.jsonWatch 请求与响应用于核验 Watch API guaranteesoperations.jsonKV 操作历史history.htmlKV 操作历史可视化用于核验 KV API guaranteestraffic.json期望 revision 唯一性等流量细节元数据。失败时报告生成日志大致如下省略大量no watch operations for client的中间行logger.go:146: 2024-05-08T10:42:54.4290200 INFO Saving robustness test report {path: /tmp/TestRobustnessRegression_Issue14370/1715157774429416550} logger.go:146: 2024-05-08T10:42:54.4290200 INFO Saving member data dir {member: TestRobustnessRegressionIssue14370-test-0, path: /tmp/TestRobustnessRegression_Issue14370/1715157774429416550/server-TestRobustnessRegressionIssue14370-test-0} logger.go:146: 2024-05-08T10:42:54.4300200 INFO no watch operations for client, skip persisting {client-id: 1} logger.go:146: 2024-05-08T10:42:54.4300200 INFO Saving operation history {path: /tmp/TestRobustnessRegression_Issue14370/1715157774429416550/client-1/operations.json} ... logger.go:146: 2024-05-08T10:42:54.4410200 INFO Saving visualization {path: /tmp/TestRobustnessRegression_Issue14370/1715157774429416550/history.html}注意日志规则某客户端只有 KV 操作而无 Watch或反之时对应文件会被跳过不写。8.1 实例分析线性化违约#14370 单节点崩溃丢写用下述命令亲自复现多试几次后 Robustness 会以Linearization illegal报错并保存报告make test-robustness-issue14370失败日志形如logger.go:146: 2025-08-01T22:54:26.5500900 INFO Validating linearizable operations {timeout: 5m0s} logger.go:146: 2025-08-01T22:54:26.7550900 ERROR Linearization illegal {duration: 205.05225ms} logger.go:146: 2025-08-01T22:54:26.7550900 INFO Skipping other validations as linearization failed main_test.go:122: linearization: illegal logger.go:146: 2025-08-01T22:54:26.7560900 INFO Saving robustness test report {path: /tmp/TestRobustnessRegression_Issue14370/1754056466755991000} ... logger.go:146: 2025-08-01T22:54:26.8500900 INFO Saving visualization {path: /tmp/TestRobustnessRegression_Issue14370/1754056466755991000/history.html} logger.go:146: 2025-08-01T22:54:26.8780900 INFO killing server... {name: TestRobustnessRegressionIssue14370-test-0}分析线性化问题最直观的入口是可视化文件。用浏览器打开/tmp/TestRobustnessRegression_Issue14370/1754056466755991000/history.html点击页面顶部的[ jump to first error ]跳转到第一个错误处会看到类似下图的线性化时序图图中解读最后一次正确请求灰色连线是一次成功且拿到revision 168的Put其后的所有请求红色连线都不合法因为它们拿到的都是revision 167。etcd 承诺 revision 单调不减因此先 168 再 167在语义上不可能成立——这恰好与 #14370 的根因吻合进程崩溃导致最后一次写入丢失单节点在崩溃恢复后回退了已确认的写入。8.2 实例分析Watch 违约#15271 网络分区后 Watch 回放旧事件make test-robustness-issue15271多试几次后日志会出现Broke watch guaranteelogger.go:146: 2024-05-08T10:50:11.3010200 INFO Validating linearizable operations {timeout: 5m0s} logger.go:146: 2024-05-08T10:50:15.7540200 INFO Linearization success {duration: 4.453346487s} logger.go:146: 2024-05-08T10:50:15.7540200 INFO Validating watch logger.go:146: 2024-05-08T10:50:15.8490200 ERROR Broke watch guarantee {guarantee: ordered, client: 4, revision: 3} validate.go:45: Failed validating watch history, err: broke Ordered - events are ordered by revision; an event will never appear on a watch if it precedes an event in time that has already been posted logger.go:146: 2024-05-08T10:50:15.8660200 INFO Saving robustness test report {path: /tmp/TestRobustnessRegression_Issue15271/1715158215866033806}Watch 问题最便于通过逐客户端保存的 watch 历史分析报告根目录下每个客户端一个子目录找出日志中违约客户端的watch.json——上面的日志指明 client4因此打开/tmp/TestRobustnessRegression_Issue15271/1715158215866033806/client-4/watch.json。文件每行是一个 JSON 对象对应客户端发出的一次 Watch 请求找到Revision:3的事件{Events:[{Type:put-operation,Key:key5,Value:{Value:793,Hash:0},Revision:799,IsCreate:false,PrevValue:null}],IsProgressNotify:false,Revision:799,Time:3202907249,Error:} {Events:[{Type:put-operation,Key:key4,Value:{Value:1,Hash:0},Revision:3,IsCreate:true,PrevValue:null}, ...到第一行之前事件 revision 一路只增到799而紧接的下一条响应里却出现Revision为3的事件——沿着文件继续读会发现 revision 被二次回放。这与 #15271 的根因吻合分区期间落后的成员重连集群后把早已推送过的历史 revision 重新发给了 Watch 客户端从而违反Ordered保证该保证要求已经推送过的更晚事件不会在其后再出现更早事件。这正是 validate/watch.go 中validateOrdered逐条比对相邻事件 revision 单调性所抓到的场景。九、小结把 Robustness 用起来etcd 的 Robustness 测试框架回答了一个其他测试很少认真回答的问题在真的发生事故时etcd 还守得住它承诺的那些一致性语义吗。它的方法论可以完整沉淀为一条可复用链路——1用 gofail 构造可注入故障的二进制2在健康集群上并行注入流量、Watch 与随机故障3用 porcupine 确定性 etcd 模型校验操作历史是否可线性化用 WAL 回放逐条核验 Watch 保证4失败即产出含 WAL、快照 db、operations.json、watch.json与history.html的完整证据包5把失败报告沉入testdata用新模型持续回归。无论你是 etcd 的深度用户、Kubernetes 存储链路维护者还是想为自己的分布式系统构建故障下语义保证测试体系都可以把本文的复现命令make test-robustness-issue14370等、报告分析套路与源码入口tests/robustness 下的main_test.go、validate、model、failpoint、report各包当作直接可用的参考范本。【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考