消息队列流处理后端微服务消息路由【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pu/pulsar点击查看免费下载PIP-56Python3 Migration是 Apache Pulsar 社区提出的将默认 Python 运行时从 2.7 迁移到 3.7 的改进提案。本文以该提案为核心结合当前仓库中 docker/pulsar/Dockerfile、docker/pulsar/Dockerfile.wolfi 以及 Pulsar Functions Python 运行时源码讲解迁移的背景、影响面、落地改动与验证方法帮助你理解 Pulsar 镜像中 Python 运行时的演进逻辑并掌握自定义 Python 版本镜像的构建思路。PIP-56 提案背景Python 2.7 的 End of LifePython 2.7 于 2020 年 1 月 1 日正式停止官方维护End of Life。而在此之前的较长一段时间里Apache Pulsar 存在两个与 Python 2 深度绑定的现实PyPI 上发布的 Python 客户端制品仍是 Python 2.x 兼容的构件社区持续在 pypi 上分发 python 2 的 wheel 包Pulsar 官方镜像中 Python 2.7 是默认运行时这直接影响两类用户依赖 Python 客户端的安装场景使用 Python 编写 Pulsar Functions、并直接运行在官方镜像上的函数用户。PIP-56 正是针对这一现状提出的系统性迁移提案其核心主张包含三点将 Pulsar 镜像中的默认 Python 版本从 python27 升级到 python37将集成测试integration test迁移到 python37 运行时上执行公告 Python 3.7 的弃用节奏同时承诺在 2020 年底前继续支持 python27 制品。影响分析谁会被这次默认运行时变更波及提案明确指出变更默认 Python 安装会给两类群体带来直接冲击使用 Python 客户端的安装场景如果默认 Python 解释器从 2 变为 3依赖旧解释器行为或旧版本依赖树的部署会受到破坏且不存在简单的自动迁移路径运行 Python Functions 的用户官方镜像内预置的 Python 运行时一旦切换函数运行环境随之变化需要用户重新验证函数代码的 Python 3 兼容性。与此同时迁移带来的一个必然结果是python27 的测试覆盖会逐步缩减因为默认集成测试将显式针对 python37 运行。提案给出的缓解策略是通过**明确的发布说明release notes**通知受影响用户提供构建自定义镜像、以 python27 为默认解释器的操作指引在当年年底之前继续发布 python27 制品为存量用户留出过渡窗口。需要落地的改动清单PIP-56 将改动范围圈定在少量 docker 与 pom 文件中具体包括移除 Python 2 的安装步骤删除 Pulsar 镜像 Dockerfile 中 python2 的安装行以及 dashboard 镜像 Dockerfile 中的对应安装逻辑添加符号链接建立python3 - python、pip3 - pip的 symlink使既有脚本和用户在无感知的情况下使用 Python 3移除 Python 27 wheel 的安装不再在镜像中安装面向 python27 的客户端 wheel。需要说明提案引用的 Dockerfile 行号对应的是提案撰写时的历史版本。当前仓库中的镜像定义已经历多轮演进Alpine 基础镜像、Wolfi 基础镜像、JDK 25/21、mimalloc 预加载等但Python 3 为唯一默认运行时这一结论已在 docker/pulsar/Dockerfile 与 docker/pulsar/Dockerfile.wolfi 中得到充分落实。迁移后的镜像现状源码级验证Alpine 版镜像python3 py3-pip当前 docker/pulsar/Dockerfile 的基础镜像阶段FROM alpine:$ALPINE_VERSION通过apk add安装的 Python 相关包已经完全 Python 3 化RUN apk add --no-cache \ bash \ python3 \ py3-pip \ py3-yaml \ gcompat \ libgcc \ libstdc \ libuuid \ ca-certificates \ procps \ curl \ bind-tools \ openssl \ coreutils其中python3、py3-pip、py3-yaml分别是 Python 3 解释器、pip 与 PyYAML 的 Alpine 包。py3-yaml对 Pulsar Functions 尤其重要——Functions 运行时通过 YAML 解析函数配置对应 conf/functions_worker.yml 等配置文件的使用场景。随后镜像内通过pip3安装一组与 Pulsar Functions Python 运行时严格绑定版本的依赖docker/pulsar/DockerfileARG PULSAR_CLIENT_PYTHON_VERSION RUN pip3 install --break-system-packages --no-cache-dir \ --only-binary \ grpcio1.78.0 \ protobuf6.33.6 \ pulsar-client[all]${PULSAR_CLIENT_PYTHON_VERSION} \ kazoogrpcio与protobuf的版本被显式固定且与仓库内_pb2.py生成的 stubs 保持兼容详见下文stubs 生成小节pulsar-client[all]${PULSAR_CLIENT_PYTHON_VERSION}是 Python 客户端全量依赖安装版本由构建参数注入构建时可通过--build-arg PULSAR_CLIENT_PYTHON_VERSION...覆盖kazoo用于 ZooKeeper 交互支撑 Functions 运行时的协调逻辑。Wolfi 版镜像可参数化的 Python 版本docker/pulsar/Dockerfile.wolfi 以 Chainguard Wolfi 为基础镜像Python 版本通过构建参数显式声明默认 3.12迁移思路一脉相承ARG PYTHON_VERSION3.12 RUN apk add --no-cache \ bash \ python-${PYTHON_VERSION} \ py${PYTHON_VERSION}-pip \ ...依赖安装同样使用pip3并额外补充了pyyamldocker/pulsar/Dockerfile.wolfi。可以看到PIP-56 提出的python3 为默认、pip3 为默认包管理器在两条镜像链路上都已固化为事实标准。构建自定义镜像如何让 python27 成为默认对于仍需 Python 2 的存量用户PIP-56 给出的方向是构建自定义镜像。基于当前 Dockerfile 的结构可采取以下做法仅作操作说明仓库本身不提供 python2 支持fork 或复制docker/pulsar/Dockerfile 到自己仓库将apk add中的python3替换为python2Alpine 老版本仓库或改用 Ubuntu/Debian 基础镜像中的python2.7将py3-pip、py3-yaml替换为对应的 Python 2 版本并把pip3 install改为pip install移除或替换grpcio1.78.0、protobuf6.33.6等仅支持 Python 3 的新版本依赖回退到兼容 Python 2 的历史版本如 grpcio 1.24.x、protobuf 3.x 早期版本。需要注意当前仓库的 Functions Python 运行时源码见下文对 Python 2 仅保留了有限兼容逻辑且 grpcio/protobuf 已推进到 Python 3-only 的版本线因此自定义 python2 镜像需要同步回退这些依赖才能实际运行。运行时源码中的 Python 3 迁移痕迹PIP-56 的迁移不仅体现在 DockerfilePulsar Functions 的 Python 运行时源码同样记录了从 2 到 3 的兼容与演进过程集中在 pulsar-functions/instance/src/main/python 目录入口脚本显式声明 python3pulsar-functions/instance/src/main/python/python_instance_main.py 的 shebang 为#!/usr/bin/env python3这是运行时强制 Python 3最直接的证据——无论 PATH 中的python指向哪个版本函数实例进程都会用python3解释器启动。运行时内的 Py2/Py3 兼容分支pulsar-functions/instance/src/main/python/python_instance.py 定义了版本判定常量并在多处使用条件分支PY3 sys.version_info[0] 3例如base64ify()中根据PY3决定字符串是否需要先encode(utf8)再 base64python_instance.py模块导入处也保留了try: import Queue as queue / except: import queue的双版本兼容写法python_instance.py。类似的兼容代码还出现在function_stats.pyint(...) if sys.version_info.major 3 else long(...)处理 Python 2 独有的long类型python_instance.py指标与状态上报时的int/long转换分支python_instance.py自定义 Schema 反射时inspect.signature与inspect.getargspec的双版本回退# for compatibility with python 2注释。从源码结构看这些分支是迁移过渡期留下的兼容层功能上以 Python 3 为主路径Python 2 仅保留最低限度的可用性——与 PIP-56python27 测试覆盖缩减、年底停止制品发布的路线完全一致。依赖锁定与 stubs 再生成机制Python 运行时依赖的 Protobuf/gRPC stubs 由仓库内的脚本生成与镜像中固定的grpcio/protobuf版本严格对应。相关说明见 pulsar-functions/instance/src/main/python/README.md若升级镜像中的grpcio/protobuf必须同步更新 src/update_python_protobuf_stubs.sh 中的PYTHON_GRPCIO_VERSION当前默认1.78.0见该脚本第 23 行并重新生成 stubs在项目根目录执行src/update_python_protobuf_stubs.sh或容器化的src/update_python_protobuf_stubs_with_docker.sh即可重新生成Function_pb2.py、InstanceCommunication_pb2.py、InstanceCommunication_pb2_grpc.py等文件脚本会创建临时 venv 以避免污染全局环境并使用grpc_tools.protoc从 pulsar-functions/proto/src/main/proto 下的.proto文件生成代码同时删除生成文件中的严格版本校验代码以允许跨版本运行。迁移的验证路径集成测试与运行时测试PIP-56 的第二项主张是集成测试迁移到 python37。当前仓库中与 Python Functions 相关的测试可从两个层面验证 Python 3 运行时运行时单元测试pulsar-function-go与 Python 运行时各有独立测试如 pulsar-functions/instance 下的 Python 脚本以及pf/目录中*_test.go对应的 Go 运行时测试它们共同覆盖函数实例的启动、消息处理与指标上报集成测试链路tests/integration目录下的 Java 集成测试如 tests/integration/src 中的 Pulsar Functions 相关用例负责在真实集群中验证函数端到端行为默认即运行在带 Python 3 的官方镜像之上。对于希望本地复现镜像内 Python 3 可用性的读者可执行# 构建镜像在仓库根目录需先完成完整构建以产出 tarball ./gradlew -Pdocker -PskipTests -DdockerPulltrue docker:docker # 或直接进入镜像验证运行时 docker run --rm -it apachepulsar/pulsar:latest python3 --version docker run --rm -it apachepulsar/pulsar:latest pip3 --version提示PULSAR_CLIENT_PYTHON_VERSION与PYTHON_VERSION仅 Wolfi 镜像均为可覆盖的构建参数自定义镜像时可利用--build-arg调整客户端版本。小结PIP-56 的落地与演进PIP-56 以Python 2.7 停止维护为背景提出了默认运行时从 python27 到 python37 的三步迁移方案。回看当前仓库该提案的目标已全面达成并继续演进官方镜像Alpine 与 Wolfi 两条链路只安装 Python 3python3/pip3成为默认命令Functions Python 运行时入口使用python3shebang源码中的 Py2 兼容分支仅作为历史兼容层保留grpcio/protobuf 与生成的 stubs 通过PYTHON_GRPCIO_VERSION脚本化联动保证运行时依赖与生成代码的版本一致性Python 版本进一步演进Wolfi 镜像默认 3.12客户端版本持续跟随社区发布节奏。对于依旧依赖 Python 2 的存量部署唯一的合规路径是参考 docker/pulsar/Dockerfile 自行构建自定义镜像并回退依赖版本同时关注发布说明中的兼容性公告——这正是 PIP-56 当年为社区规划好的过渡方式。赞分享消息队列流处理后端微服务消息路由【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pu/pulsar点击查看免费下载相关推荐PIP-324 深度解析Apache Pulsar Docker 镜像迁移至 Alpine Linux 基础镜像PIP 324 深度解析Apache Pulsar Docker 镜像迁移至 Alpine Linux 基础镜像 Apache Pulsar 官方 Docke消息队列后端终极指南Apache Pulsar集群零停机升级与数据迁移实战终极指南Apache Pulsar集群零停机升级与数据迁移实战 Apache Pulsar作为云原生消息队列和流处理平台其集群的平滑升级与数据迁移是保障业务消息队列流处理后端微服务消息路由Salt 3007.x onedir 运行时升级Python 3.10 迁移至 3.11 的完整运维指南Salt 3007.x onedir 运行时升级Python 3.10 迁移至 3.11 的完整运维指南 导读 本文基于 Salt 仓库 changelog运维配置管理后端上一篇终极API安全指南保护你的API密钥与安全调用最佳实践下一篇codeforces-go 题解工程化实战统计染色格子数Count Total Number of Colored Cells的 O(1) 递推公式 f(n)12n(n-1)创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Apache Pulsar Python 3 迁移实践：PIP-56 与镜像运行时升级指南
消息队列流处理后端微服务消息路由【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pu/pulsar点击查看免费下载PIP-56Python3 Migration是 Apache Pulsar 社区提出的将默认 Python 运行时从 2.7 迁移到 3.7 的改进提案。本文以该提案为核心结合当前仓库中 docker/pulsar/Dockerfile、docker/pulsar/Dockerfile.wolfi 以及 Pulsar Functions Python 运行时源码讲解迁移的背景、影响面、落地改动与验证方法帮助你理解 Pulsar 镜像中 Python 运行时的演进逻辑并掌握自定义 Python 版本镜像的构建思路。PIP-56 提案背景Python 2.7 的 End of LifePython 2.7 于 2020 年 1 月 1 日正式停止官方维护End of Life。而在此之前的较长一段时间里Apache Pulsar 存在两个与 Python 2 深度绑定的现实PyPI 上发布的 Python 客户端制品仍是 Python 2.x 兼容的构件社区持续在 pypi 上分发 python 2 的 wheel 包Pulsar 官方镜像中 Python 2.7 是默认运行时这直接影响两类用户依赖 Python 客户端的安装场景使用 Python 编写 Pulsar Functions、并直接运行在官方镜像上的函数用户。PIP-56 正是针对这一现状提出的系统性迁移提案其核心主张包含三点将 Pulsar 镜像中的默认 Python 版本从 python27 升级到 python37将集成测试integration test迁移到 python37 运行时上执行公告 Python 3.7 的弃用节奏同时承诺在 2020 年底前继续支持 python27 制品。影响分析谁会被这次默认运行时变更波及提案明确指出变更默认 Python 安装会给两类群体带来直接冲击使用 Python 客户端的安装场景如果默认 Python 解释器从 2 变为 3依赖旧解释器行为或旧版本依赖树的部署会受到破坏且不存在简单的自动迁移路径运行 Python Functions 的用户官方镜像内预置的 Python 运行时一旦切换函数运行环境随之变化需要用户重新验证函数代码的 Python 3 兼容性。与此同时迁移带来的一个必然结果是python27 的测试覆盖会逐步缩减因为默认集成测试将显式针对 python37 运行。提案给出的缓解策略是通过**明确的发布说明release notes**通知受影响用户提供构建自定义镜像、以 python27 为默认解释器的操作指引在当年年底之前继续发布 python27 制品为存量用户留出过渡窗口。需要落地的改动清单PIP-56 将改动范围圈定在少量 docker 与 pom 文件中具体包括移除 Python 2 的安装步骤删除 Pulsar 镜像 Dockerfile 中 python2 的安装行以及 dashboard 镜像 Dockerfile 中的对应安装逻辑添加符号链接建立python3 - python、pip3 - pip的 symlink使既有脚本和用户在无感知的情况下使用 Python 3移除 Python 27 wheel 的安装不再在镜像中安装面向 python27 的客户端 wheel。需要说明提案引用的 Dockerfile 行号对应的是提案撰写时的历史版本。当前仓库中的镜像定义已经历多轮演进Alpine 基础镜像、Wolfi 基础镜像、JDK 25/21、mimalloc 预加载等但Python 3 为唯一默认运行时这一结论已在 docker/pulsar/Dockerfile 与 docker/pulsar/Dockerfile.wolfi 中得到充分落实。迁移后的镜像现状源码级验证Alpine 版镜像python3 py3-pip当前 docker/pulsar/Dockerfile 的基础镜像阶段FROM alpine:$ALPINE_VERSION通过apk add安装的 Python 相关包已经完全 Python 3 化RUN apk add --no-cache \ bash \ python3 \ py3-pip \ py3-yaml \ gcompat \ libgcc \ libstdc \ libuuid \ ca-certificates \ procps \ curl \ bind-tools \ openssl \ coreutils其中python3、py3-pip、py3-yaml分别是 Python 3 解释器、pip 与 PyYAML 的 Alpine 包。py3-yaml对 Pulsar Functions 尤其重要——Functions 运行时通过 YAML 解析函数配置对应 conf/functions_worker.yml 等配置文件的使用场景。随后镜像内通过pip3安装一组与 Pulsar Functions Python 运行时严格绑定版本的依赖docker/pulsar/DockerfileARG PULSAR_CLIENT_PYTHON_VERSION RUN pip3 install --break-system-packages --no-cache-dir \ --only-binary \ grpcio1.78.0 \ protobuf6.33.6 \ pulsar-client[all]${PULSAR_CLIENT_PYTHON_VERSION} \ kazoogrpcio与protobuf的版本被显式固定且与仓库内_pb2.py生成的 stubs 保持兼容详见下文stubs 生成小节pulsar-client[all]${PULSAR_CLIENT_PYTHON_VERSION}是 Python 客户端全量依赖安装版本由构建参数注入构建时可通过--build-arg PULSAR_CLIENT_PYTHON_VERSION...覆盖kazoo用于 ZooKeeper 交互支撑 Functions 运行时的协调逻辑。Wolfi 版镜像可参数化的 Python 版本docker/pulsar/Dockerfile.wolfi 以 Chainguard Wolfi 为基础镜像Python 版本通过构建参数显式声明默认 3.12迁移思路一脉相承ARG PYTHON_VERSION3.12 RUN apk add --no-cache \ bash \ python-${PYTHON_VERSION} \ py${PYTHON_VERSION}-pip \ ...依赖安装同样使用pip3并额外补充了pyyamldocker/pulsar/Dockerfile.wolfi。可以看到PIP-56 提出的python3 为默认、pip3 为默认包管理器在两条镜像链路上都已固化为事实标准。构建自定义镜像如何让 python27 成为默认对于仍需 Python 2 的存量用户PIP-56 给出的方向是构建自定义镜像。基于当前 Dockerfile 的结构可采取以下做法仅作操作说明仓库本身不提供 python2 支持fork 或复制docker/pulsar/Dockerfile 到自己仓库将apk add中的python3替换为python2Alpine 老版本仓库或改用 Ubuntu/Debian 基础镜像中的python2.7将py3-pip、py3-yaml替换为对应的 Python 2 版本并把pip3 install改为pip install移除或替换grpcio1.78.0、protobuf6.33.6等仅支持 Python 3 的新版本依赖回退到兼容 Python 2 的历史版本如 grpcio 1.24.x、protobuf 3.x 早期版本。需要注意当前仓库的 Functions Python 运行时源码见下文对 Python 2 仅保留了有限兼容逻辑且 grpcio/protobuf 已推进到 Python 3-only 的版本线因此自定义 python2 镜像需要同步回退这些依赖才能实际运行。运行时源码中的 Python 3 迁移痕迹PIP-56 的迁移不仅体现在 DockerfilePulsar Functions 的 Python 运行时源码同样记录了从 2 到 3 的兼容与演进过程集中在 pulsar-functions/instance/src/main/python 目录入口脚本显式声明 python3pulsar-functions/instance/src/main/python/python_instance_main.py 的 shebang 为#!/usr/bin/env python3这是运行时强制 Python 3最直接的证据——无论 PATH 中的python指向哪个版本函数实例进程都会用python3解释器启动。运行时内的 Py2/Py3 兼容分支pulsar-functions/instance/src/main/python/python_instance.py 定义了版本判定常量并在多处使用条件分支PY3 sys.version_info[0] 3例如base64ify()中根据PY3决定字符串是否需要先encode(utf8)再 base64python_instance.py模块导入处也保留了try: import Queue as queue / except: import queue的双版本兼容写法python_instance.py。类似的兼容代码还出现在function_stats.pyint(...) if sys.version_info.major 3 else long(...)处理 Python 2 独有的long类型python_instance.py指标与状态上报时的int/long转换分支python_instance.py自定义 Schema 反射时inspect.signature与inspect.getargspec的双版本回退# for compatibility with python 2注释。从源码结构看这些分支是迁移过渡期留下的兼容层功能上以 Python 3 为主路径Python 2 仅保留最低限度的可用性——与 PIP-56python27 测试覆盖缩减、年底停止制品发布的路线完全一致。依赖锁定与 stubs 再生成机制Python 运行时依赖的 Protobuf/gRPC stubs 由仓库内的脚本生成与镜像中固定的grpcio/protobuf版本严格对应。相关说明见 pulsar-functions/instance/src/main/python/README.md若升级镜像中的grpcio/protobuf必须同步更新 src/update_python_protobuf_stubs.sh 中的PYTHON_GRPCIO_VERSION当前默认1.78.0见该脚本第 23 行并重新生成 stubs在项目根目录执行src/update_python_protobuf_stubs.sh或容器化的src/update_python_protobuf_stubs_with_docker.sh即可重新生成Function_pb2.py、InstanceCommunication_pb2.py、InstanceCommunication_pb2_grpc.py等文件脚本会创建临时 venv 以避免污染全局环境并使用grpc_tools.protoc从 pulsar-functions/proto/src/main/proto 下的.proto文件生成代码同时删除生成文件中的严格版本校验代码以允许跨版本运行。迁移的验证路径集成测试与运行时测试PIP-56 的第二项主张是集成测试迁移到 python37。当前仓库中与 Python Functions 相关的测试可从两个层面验证 Python 3 运行时运行时单元测试pulsar-function-go与 Python 运行时各有独立测试如 pulsar-functions/instance 下的 Python 脚本以及pf/目录中*_test.go对应的 Go 运行时测试它们共同覆盖函数实例的启动、消息处理与指标上报集成测试链路tests/integration目录下的 Java 集成测试如 tests/integration/src 中的 Pulsar Functions 相关用例负责在真实集群中验证函数端到端行为默认即运行在带 Python 3 的官方镜像之上。对于希望本地复现镜像内 Python 3 可用性的读者可执行# 构建镜像在仓库根目录需先完成完整构建以产出 tarball ./gradlew -Pdocker -PskipTests -DdockerPulltrue docker:docker # 或直接进入镜像验证运行时 docker run --rm -it apachepulsar/pulsar:latest python3 --version docker run --rm -it apachepulsar/pulsar:latest pip3 --version提示PULSAR_CLIENT_PYTHON_VERSION与PYTHON_VERSION仅 Wolfi 镜像均为可覆盖的构建参数自定义镜像时可利用--build-arg调整客户端版本。小结PIP-56 的落地与演进PIP-56 以Python 2.7 停止维护为背景提出了默认运行时从 python27 到 python37 的三步迁移方案。回看当前仓库该提案的目标已全面达成并继续演进官方镜像Alpine 与 Wolfi 两条链路只安装 Python 3python3/pip3成为默认命令Functions Python 运行时入口使用python3shebang源码中的 Py2 兼容分支仅作为历史兼容层保留grpcio/protobuf 与生成的 stubs 通过PYTHON_GRPCIO_VERSION脚本化联动保证运行时依赖与生成代码的版本一致性Python 版本进一步演进Wolfi 镜像默认 3.12客户端版本持续跟随社区发布节奏。对于依旧依赖 Python 2 的存量部署唯一的合规路径是参考 docker/pulsar/Dockerfile 自行构建自定义镜像并回退依赖版本同时关注发布说明中的兼容性公告——这正是 PIP-56 当年为社区规划好的过渡方式。赞分享消息队列流处理后端微服务消息路由【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pu/pulsar点击查看免费下载相关推荐PIP-324 深度解析Apache Pulsar Docker 镜像迁移至 Alpine Linux 基础镜像PIP 324 深度解析Apache Pulsar Docker 镜像迁移至 Alpine Linux 基础镜像 Apache Pulsar 官方 Docke消息队列后端终极指南Apache Pulsar集群零停机升级与数据迁移实战终极指南Apache Pulsar集群零停机升级与数据迁移实战 Apache Pulsar作为云原生消息队列和流处理平台其集群的平滑升级与数据迁移是保障业务消息队列流处理后端微服务消息路由Salt 3007.x onedir 运行时升级Python 3.10 迁移至 3.11 的完整运维指南Salt 3007.x onedir 运行时升级Python 3.10 迁移至 3.11 的完整运维指南 导读 本文基于 Salt 仓库 changelog运维配置管理后端上一篇终极API安全指南保护你的API密钥与安全调用最佳实践下一篇codeforces-go 题解工程化实战统计染色格子数Count Total Number of Colored Cells的 O(1) 递推公式 f(n)12n(n-1)创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考