Argo CD v2.2 到 v2.3 升级指南组件内置、CLI 二进制下载配置与 SSH 签名算法变更【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd本篇技术指南围绕 Argo CD 从 v2.2 升级到 v2.3 的官方升级文档系统梳理该版本中组件打包方式、镜像内容、内置工具链版本以及 SSH 认证行为等关键变更并结合当前仓库源码与配置清单给出可复现的操作步骤。读者读完本篇后能够判断自己的部署方式kubectl apply / Kustomize / Helm是否需要调整能够通过argocd-cmConfigMap 配置多平台 CLI 下载入口并能在升级到 2.3.7 前完成 SSH 兼容性检查与规避方案落地。升级总览v2.2 → v2.3 的核心变化v2.2 到 v2.3 的升级并不涉及数据迁移或 API 破坏性变更重点集中在以下几类运行时变化组件打包方式变化Argo CD Notifications 与 ApplicationSet 正式并入 Argo CD 本体镜像内容变化移除非 Linux 平台 CLI 二进制、移除 Python 运行时内置工具链升级Kustomize 由 4.2.0 升级到 4.4.1Helm 由 3.7.1 升级到 3.8.0安全策略收紧2.3.7 起基础镜像升级到 Ubuntu 22.04OpenSSH 升级到 8.9不再支持ssh-rsaSHA-1 签名算法。本文的升级目标版本是 v2.3如需查看其他版本间的升级说明可参考 升级总览文档其中列出了全部相邻版本升级指南的入口。Argo CD Notifications 与 ApplicationSet 正式内置变更内容从 v2.3 开始Argo CD Notifications通知控制器和 ApplicationSet 控制器已成为 Argo CD 发行的一部分无需再单独安装这两个组件。默认的 Argo CD 安装清单manifest已经内置了它们。这一变化在当前仓库的 manifest 结构中可以直接得到印证manifests/base/kustomization.yaml的resources列表同时包含了./notification与./applicationset-controller与 application-controller、dex、repo-server、server、redis 等核心组件并列resources: - ./application-controller - ./dex - ./repo-server - ./server - ./config - ./redis - ./notification - ./applicationset-controller对应的manifests/base/notification/目录下包含 notifications 控制器的 Deployment、ServiceAccount、RBAC、ConfigMap、Secret 以及指标采集 Service 等完整资源manifests/base/applicationset-controller/目录同样包含 ApplicationSet 控制器所需的完整资源。在代码层面仓库根目录的notification_controller/包实现了通知控制器逻辑applicationset/目录则包含 ApplicationSet 控制器的核心实现。不同部署方式下的操作指引使用kubectl apply部署的用户无需任何操作。新清单会自动带上内置组件。使用 Kustomize 组装清单的用户内置清单是旧版独立安装的“drop-in 替换”。如果你之前在 Kustomize 中引用了argoproj-labs/argocd-notifications和argoproj-labs/applicationset仓库的清单直接删除这些引用即可同时移除对应的kustomization.yaml中相应资源块。使用 argocd-notifications Helm chart 的用户可以将原 chart 的 values 迁移到 argo-cd chart values 中的notifications一节。绝大部分配置项保持原样个别字段需要对照当前 argo-cd chart 的 values 文档逐一核对与调整。注意当前仓库 VERSION 文件显示仓库基线已演进到 3.6.0但上述“组件内置”的布局自 v2.3 起即已确立并延续至今。配置额外的 Argo CD CLI 下载入口变更背景v2.3 起Argo CD 镜像中移除了非 Linux 平台的 CLI 二进制包括 Darwin amd64 和 Windows amd64UI 帮助页面中对应的下载按钮也随之移除。被移除的二进制仍然会作为 release assets 发布只是不再打进镜像。为了保持多平台 CLI 的可获取性社区通过配置项将其重新开放你可以在argocd-cmConfigMap 中添加help.download.os-arch键为帮助页面配置指向任意下载地址的按钮。官方默认清单中的完整示例可参见 argocd-cm.yamlapiVersion: v1 kind: ConfigMap metadata: name: argocd-cm namespace: argocd labels: app.kubernetes.io/name: argocd-cm app.kubernetes.io/part-of: argocd data: help.download.linux-amd64: path-or-url-to-download help.download.linux-arm64: path-or-url-to-download help.download.linux-ppc64le: path-or-url-to-download help.download.linux-s390x: path-or-url-to-download help.download.darwin-amd64: path-or-url-to-download help.download.darwin-arm64: path-or-url-to-download help.download.windows-amd64: path-or-url-to-download支持的操作系统与架构列表从当前仓库源码看Argo CD 仅识别以下os-arch组合其余键会被忽略。相关逻辑位于 util/settings/settings.go 的getDownloadBinaryUrlsFromConfigMap函数它会遍历固定列表并逐个读取 ConfigMap 数据linux-amd64linux-arm64linux-ppc64lelinux-s390xdarwin-amd64darwin-arm64windows-amd64对应测试 util/settings/settings_test.go 验证了这一行为配置help.download.darwin-amd64、help.download.linux-s390x和不受支持的help.download.unsupported时最终只有前两个被识别进BinaryURLs映射未列出的键被静默忽略。使用注意事项帮助页面Help page始终默认展示一个内置的 Linux CLI 下载按钮无需任何配置即可让用户获取可用的 CLI如果你为服务器自身架构额外配置了help.download.linux-arch页面上会出现两个 Linux 按钮一个默认按钮加一个自定义按钮这是预期行为详见 UI 自定义文档键对应的值可以是路径或完整 URL例如https://example.com/argocd-darwin-arm64Argo CD 只负责在帮助页面渲染指向该地址的下载按钮不校验地址可达性。基础镜像移除了 Pythonv2.3 起Argo CD 基础镜像不再包含 Python 运行时。如果你正在使用依赖 Python 的 Config Management Plugin配置管理插件CMP升级后插件将无法在容器内找到 Python 解释器。解决方案是基于 Argo CD 官方镜像构建自定义镜像在镜像中自行安装 Python然后让 repo-server 使用该自定义镜像运行。具体做法为编写 Dockerfile基于quay.io/argoproj/argocd:版本安装所需 Python 版本及其依赖将自定义镜像发布到镜像仓库修改 Argo CD 部署清单中 repo-server 的镜像引用确保 CMP 的command配置指向正确的可执行文件路径必要时使用绝对路径如/usr/local/bin/python3。内置 Kustomize 版本升级4.2.0 → 4.4.1v2.3 将内置 Kustomize 从 4.2.0 升级到 4.4.1。这意味着应用仓库中使用的 Kustomize 特性集会随之变化升级前建议检查应用仓库中是否使用了 4.2.0 不支持、或行为与 4.4.1 不一致的 Kustomize 语法如patchesJson6902、replacements相关特性在不同小版本间的行为差异在测试环境中对存量 Application 执行一次 dry-run 或 Sync 演练确认生成的 manifest 与预期一致。从当前仓库的依赖看Kustomize 组件已演进到更新版本go.mod中sigs.k8s.io/kustomize/api v0.21.1为当前基线说明 Argo CD 对 Kustomize 的升级是持续进行的本升级指南所述 4.4.1 是 v2.3 发布时的内置版本。内置 Helm 版本升级3.7.1 → 3.8.0v2.3 同时将内置 Helm 从 3.7.1 升级到 3.8.0。Helm 3.8 带来的变化包括更严格的依赖校验行为与部分模板函数行为的调整。建议在升级 Argo CD 前在本地使用 Helm 3.8.0 对使用 Helm 模板的应用执行helm template渲染比对渲染结果关注 Helm 3.8 release notes 中关于--insecure-skip-tls-verify、OCI registry 支持等与 Argo CD 集成路径相关的改动若应用使用了 Helm chart 依赖注意重新执行helm dependency update以刷新Chart.lock。2.3.7 起移除 SSH SHA-1 签名算法支持变更背景Argo CD 2.3.7 将基础镜像从 Ubuntu 21.04 升级到 Ubuntu 22.04随之 OpenSSH 升级到 8.9。OpenSSH 自 8.8 起默认禁用了ssh-rsa公钥签名算法SHA-1因此 Argo CD 在连接仅支持ssh-rsa签名算法的 Git 服务器时会出现协商失败。这里需要特别澄清一个常见误解签名算法与生成密钥时使用的算法不是一回事。ssh-keygen生成密钥的算法如 RSA不必变更你现有的私钥无需重新生成受影响的是连接建立时客户端与服务端协商的“签名算法”signature algorithm列表。签名算法的协商过程如下SSH 客户端在建立连接时向服务端提交其支持的签名算法列表服务端若有匹配项则连接继续。大多数主流 Git 服务商如 GitHub、GitLab 等的 SSH 服务器都已支持除ssh-rsa之外的其他算法因此通常不受影响。升级前检查步骤在升级到 Argo CD 2.3.7 之前请按以下步骤检查你的 Git 提供方是否支持比rsa-ssh更新的签名算法第一步确认本地 SSH 版本 ≥ 8.9即 Argo CD 所使用的版本不满足则先升级ssh -V示例输出OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022第二步从允许列表中移除ssh-rsa后尝试连接验证服务器是否仍可用其他主机密钥类型完成认证ssh -oHostKeyAlgorithms-ssh-rsa userhost若连接成功说明服务器支持更新的签名算法无需处理若主机密钥校验失败且没有其他受支持的主机密钥类型可用则说明该服务器软件需要升级。失败时的典型报错如下$ ssh -oHostKeyAlgorithms-ssh-rsa vs-ssh.visualstudio.com Unable to negotiate with 20.42.134.1 port 22: no matching host key type found. Their offer: ssh-rsa出现上述错误意味着服务器只提供ssh-rsa这一种签名算法Argo CD 将无法连接该服务器需要先推动服务器侧升级其支持的签名算法。变通方案Workaround如果暂时无法更改服务器的签名算法配置可以参考 OpenSSH 8.8 release notes 提供的临时规避手段在 SSH 客户端配置中选择性重新启用 RSA/SHA1。例如在~/.ssh/config中为单个目标主机添加如下配置段Host old-host HostkeyAlgorithms ssh-rsa PubkeyAcceptedAlgorithms ssh-rsa将该方案应用到 Argo CD 时可以创建一个包含上述 ssh 配置内容的 ConfigMap并将其挂载到 repo-server或其他需要 SSH 访问的组件容器内的/home/argocd/.ssh/config路径。示例步骤如下apiVersion: v1 kind: ConfigMap metadata: name: argocd-ssh-config namespace: argocd data: config: | Host old-host HostkeyAlgorithms ssh-rsa PubkeyAcceptedAlgorithms ssh-rsa然后在 repo-server 的 Deployment 中挂载该 ConfigMapvolumeMounts: - name: ssh-config mountPath: /home/argocd/.ssh/config subPath: config官方强烈建议仅在过渡期使用 RSA/SHA1 重启用方案直到旧版服务器完成升级或改用其他密钥类型如 ECDSA 或 Ed25519。重新启用 SHA-1 签名算法会削弱连接的安全性应尽快消除这一依赖。升级检查清单小结变更项影响范围需要采取的动作Notifications/ApplicationSet 内置所有部署方式kubectl apply无需操作Kustomize 删除外部引用Helm 迁移 values 到notifications节移除非 Linux CLI 二进制UI 帮助页按需在argocd-cm配置help.download.os-arch移除 Python依赖 Python 的 CMP 用户构建并部署自定义 repo-server 镜像Kustomize 4.2.0 → 4.4.1使用 Kustomize 的应用测试环境验证渲染结果Helm 3.7.1 → 3.8.0使用 Helm 的应用本地用 3.8.0 预渲染验证移除 ssh-rsa SHA-1 签名使用 SSH 认证的私有仓库2.3.7 起升级前用ssh -oHostKeyAlgorithms-ssh-rsa检查服务器必要时以 ConfigMap 挂载 ssh config 临时放行升级完成后建议通过argocd app list确认应用状态正常并核对帮助页面中的 CLI 下载入口与仓库 SSH 连接日志确保上述变更均已按预期生效。如需回看其他版本间的升级注意事项请查阅 升级总览。【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Argo CD v2.2 到 v2.3 升级指南：组件内置、CLI 二进制下载配置与 SSH 签名算法变更
Argo CD v2.2 到 v2.3 升级指南组件内置、CLI 二进制下载配置与 SSH 签名算法变更【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd本篇技术指南围绕 Argo CD 从 v2.2 升级到 v2.3 的官方升级文档系统梳理该版本中组件打包方式、镜像内容、内置工具链版本以及 SSH 认证行为等关键变更并结合当前仓库源码与配置清单给出可复现的操作步骤。读者读完本篇后能够判断自己的部署方式kubectl apply / Kustomize / Helm是否需要调整能够通过argocd-cmConfigMap 配置多平台 CLI 下载入口并能在升级到 2.3.7 前完成 SSH 兼容性检查与规避方案落地。升级总览v2.2 → v2.3 的核心变化v2.2 到 v2.3 的升级并不涉及数据迁移或 API 破坏性变更重点集中在以下几类运行时变化组件打包方式变化Argo CD Notifications 与 ApplicationSet 正式并入 Argo CD 本体镜像内容变化移除非 Linux 平台 CLI 二进制、移除 Python 运行时内置工具链升级Kustomize 由 4.2.0 升级到 4.4.1Helm 由 3.7.1 升级到 3.8.0安全策略收紧2.3.7 起基础镜像升级到 Ubuntu 22.04OpenSSH 升级到 8.9不再支持ssh-rsaSHA-1 签名算法。本文的升级目标版本是 v2.3如需查看其他版本间的升级说明可参考 升级总览文档其中列出了全部相邻版本升级指南的入口。Argo CD Notifications 与 ApplicationSet 正式内置变更内容从 v2.3 开始Argo CD Notifications通知控制器和 ApplicationSet 控制器已成为 Argo CD 发行的一部分无需再单独安装这两个组件。默认的 Argo CD 安装清单manifest已经内置了它们。这一变化在当前仓库的 manifest 结构中可以直接得到印证manifests/base/kustomization.yaml的resources列表同时包含了./notification与./applicationset-controller与 application-controller、dex、repo-server、server、redis 等核心组件并列resources: - ./application-controller - ./dex - ./repo-server - ./server - ./config - ./redis - ./notification - ./applicationset-controller对应的manifests/base/notification/目录下包含 notifications 控制器的 Deployment、ServiceAccount、RBAC、ConfigMap、Secret 以及指标采集 Service 等完整资源manifests/base/applicationset-controller/目录同样包含 ApplicationSet 控制器所需的完整资源。在代码层面仓库根目录的notification_controller/包实现了通知控制器逻辑applicationset/目录则包含 ApplicationSet 控制器的核心实现。不同部署方式下的操作指引使用kubectl apply部署的用户无需任何操作。新清单会自动带上内置组件。使用 Kustomize 组装清单的用户内置清单是旧版独立安装的“drop-in 替换”。如果你之前在 Kustomize 中引用了argoproj-labs/argocd-notifications和argoproj-labs/applicationset仓库的清单直接删除这些引用即可同时移除对应的kustomization.yaml中相应资源块。使用 argocd-notifications Helm chart 的用户可以将原 chart 的 values 迁移到 argo-cd chart values 中的notifications一节。绝大部分配置项保持原样个别字段需要对照当前 argo-cd chart 的 values 文档逐一核对与调整。注意当前仓库 VERSION 文件显示仓库基线已演进到 3.6.0但上述“组件内置”的布局自 v2.3 起即已确立并延续至今。配置额外的 Argo CD CLI 下载入口变更背景v2.3 起Argo CD 镜像中移除了非 Linux 平台的 CLI 二进制包括 Darwin amd64 和 Windows amd64UI 帮助页面中对应的下载按钮也随之移除。被移除的二进制仍然会作为 release assets 发布只是不再打进镜像。为了保持多平台 CLI 的可获取性社区通过配置项将其重新开放你可以在argocd-cmConfigMap 中添加help.download.os-arch键为帮助页面配置指向任意下载地址的按钮。官方默认清单中的完整示例可参见 argocd-cm.yamlapiVersion: v1 kind: ConfigMap metadata: name: argocd-cm namespace: argocd labels: app.kubernetes.io/name: argocd-cm app.kubernetes.io/part-of: argocd data: help.download.linux-amd64: path-or-url-to-download help.download.linux-arm64: path-or-url-to-download help.download.linux-ppc64le: path-or-url-to-download help.download.linux-s390x: path-or-url-to-download help.download.darwin-amd64: path-or-url-to-download help.download.darwin-arm64: path-or-url-to-download help.download.windows-amd64: path-or-url-to-download支持的操作系统与架构列表从当前仓库源码看Argo CD 仅识别以下os-arch组合其余键会被忽略。相关逻辑位于 util/settings/settings.go 的getDownloadBinaryUrlsFromConfigMap函数它会遍历固定列表并逐个读取 ConfigMap 数据linux-amd64linux-arm64linux-ppc64lelinux-s390xdarwin-amd64darwin-arm64windows-amd64对应测试 util/settings/settings_test.go 验证了这一行为配置help.download.darwin-amd64、help.download.linux-s390x和不受支持的help.download.unsupported时最终只有前两个被识别进BinaryURLs映射未列出的键被静默忽略。使用注意事项帮助页面Help page始终默认展示一个内置的 Linux CLI 下载按钮无需任何配置即可让用户获取可用的 CLI如果你为服务器自身架构额外配置了help.download.linux-arch页面上会出现两个 Linux 按钮一个默认按钮加一个自定义按钮这是预期行为详见 UI 自定义文档键对应的值可以是路径或完整 URL例如https://example.com/argocd-darwin-arm64Argo CD 只负责在帮助页面渲染指向该地址的下载按钮不校验地址可达性。基础镜像移除了 Pythonv2.3 起Argo CD 基础镜像不再包含 Python 运行时。如果你正在使用依赖 Python 的 Config Management Plugin配置管理插件CMP升级后插件将无法在容器内找到 Python 解释器。解决方案是基于 Argo CD 官方镜像构建自定义镜像在镜像中自行安装 Python然后让 repo-server 使用该自定义镜像运行。具体做法为编写 Dockerfile基于quay.io/argoproj/argocd:版本安装所需 Python 版本及其依赖将自定义镜像发布到镜像仓库修改 Argo CD 部署清单中 repo-server 的镜像引用确保 CMP 的command配置指向正确的可执行文件路径必要时使用绝对路径如/usr/local/bin/python3。内置 Kustomize 版本升级4.2.0 → 4.4.1v2.3 将内置 Kustomize 从 4.2.0 升级到 4.4.1。这意味着应用仓库中使用的 Kustomize 特性集会随之变化升级前建议检查应用仓库中是否使用了 4.2.0 不支持、或行为与 4.4.1 不一致的 Kustomize 语法如patchesJson6902、replacements相关特性在不同小版本间的行为差异在测试环境中对存量 Application 执行一次 dry-run 或 Sync 演练确认生成的 manifest 与预期一致。从当前仓库的依赖看Kustomize 组件已演进到更新版本go.mod中sigs.k8s.io/kustomize/api v0.21.1为当前基线说明 Argo CD 对 Kustomize 的升级是持续进行的本升级指南所述 4.4.1 是 v2.3 发布时的内置版本。内置 Helm 版本升级3.7.1 → 3.8.0v2.3 同时将内置 Helm 从 3.7.1 升级到 3.8.0。Helm 3.8 带来的变化包括更严格的依赖校验行为与部分模板函数行为的调整。建议在升级 Argo CD 前在本地使用 Helm 3.8.0 对使用 Helm 模板的应用执行helm template渲染比对渲染结果关注 Helm 3.8 release notes 中关于--insecure-skip-tls-verify、OCI registry 支持等与 Argo CD 集成路径相关的改动若应用使用了 Helm chart 依赖注意重新执行helm dependency update以刷新Chart.lock。2.3.7 起移除 SSH SHA-1 签名算法支持变更背景Argo CD 2.3.7 将基础镜像从 Ubuntu 21.04 升级到 Ubuntu 22.04随之 OpenSSH 升级到 8.9。OpenSSH 自 8.8 起默认禁用了ssh-rsa公钥签名算法SHA-1因此 Argo CD 在连接仅支持ssh-rsa签名算法的 Git 服务器时会出现协商失败。这里需要特别澄清一个常见误解签名算法与生成密钥时使用的算法不是一回事。ssh-keygen生成密钥的算法如 RSA不必变更你现有的私钥无需重新生成受影响的是连接建立时客户端与服务端协商的“签名算法”signature algorithm列表。签名算法的协商过程如下SSH 客户端在建立连接时向服务端提交其支持的签名算法列表服务端若有匹配项则连接继续。大多数主流 Git 服务商如 GitHub、GitLab 等的 SSH 服务器都已支持除ssh-rsa之外的其他算法因此通常不受影响。升级前检查步骤在升级到 Argo CD 2.3.7 之前请按以下步骤检查你的 Git 提供方是否支持比rsa-ssh更新的签名算法第一步确认本地 SSH 版本 ≥ 8.9即 Argo CD 所使用的版本不满足则先升级ssh -V示例输出OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022第二步从允许列表中移除ssh-rsa后尝试连接验证服务器是否仍可用其他主机密钥类型完成认证ssh -oHostKeyAlgorithms-ssh-rsa userhost若连接成功说明服务器支持更新的签名算法无需处理若主机密钥校验失败且没有其他受支持的主机密钥类型可用则说明该服务器软件需要升级。失败时的典型报错如下$ ssh -oHostKeyAlgorithms-ssh-rsa vs-ssh.visualstudio.com Unable to negotiate with 20.42.134.1 port 22: no matching host key type found. Their offer: ssh-rsa出现上述错误意味着服务器只提供ssh-rsa这一种签名算法Argo CD 将无法连接该服务器需要先推动服务器侧升级其支持的签名算法。变通方案Workaround如果暂时无法更改服务器的签名算法配置可以参考 OpenSSH 8.8 release notes 提供的临时规避手段在 SSH 客户端配置中选择性重新启用 RSA/SHA1。例如在~/.ssh/config中为单个目标主机添加如下配置段Host old-host HostkeyAlgorithms ssh-rsa PubkeyAcceptedAlgorithms ssh-rsa将该方案应用到 Argo CD 时可以创建一个包含上述 ssh 配置内容的 ConfigMap并将其挂载到 repo-server或其他需要 SSH 访问的组件容器内的/home/argocd/.ssh/config路径。示例步骤如下apiVersion: v1 kind: ConfigMap metadata: name: argocd-ssh-config namespace: argocd data: config: | Host old-host HostkeyAlgorithms ssh-rsa PubkeyAcceptedAlgorithms ssh-rsa然后在 repo-server 的 Deployment 中挂载该 ConfigMapvolumeMounts: - name: ssh-config mountPath: /home/argocd/.ssh/config subPath: config官方强烈建议仅在过渡期使用 RSA/SHA1 重启用方案直到旧版服务器完成升级或改用其他密钥类型如 ECDSA 或 Ed25519。重新启用 SHA-1 签名算法会削弱连接的安全性应尽快消除这一依赖。升级检查清单小结变更项影响范围需要采取的动作Notifications/ApplicationSet 内置所有部署方式kubectl apply无需操作Kustomize 删除外部引用Helm 迁移 values 到notifications节移除非 Linux CLI 二进制UI 帮助页按需在argocd-cm配置help.download.os-arch移除 Python依赖 Python 的 CMP 用户构建并部署自定义 repo-server 镜像Kustomize 4.2.0 → 4.4.1使用 Kustomize 的应用测试环境验证渲染结果Helm 3.7.1 → 3.8.0使用 Helm 的应用本地用 3.8.0 预渲染验证移除 ssh-rsa SHA-1 签名使用 SSH 认证的私有仓库2.3.7 起升级前用ssh -oHostKeyAlgorithms-ssh-rsa检查服务器必要时以 ConfigMap 挂载 ssh config 临时放行升级完成后建议通过argocd app list确认应用状态正常并核对帮助页面中的 CLI 下载入口与仓库 SSH 连接日志确保上述变更均已按预期生效。如需回看其他版本间的升级注意事项请查阅 升级总览。【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
