简介Protobuf 2.6.0 是 Google 开源的结构化数据序列化方案的一个稳定版本面向需要跨语言、跨平台交换数据的后端开发、RPC 通信与存储场景适合具备 C、Java、Python 等基础的中级开发者查阅使用。压缩包共 657 个文件约 3.15MB以 C 源码与头文件cc、h为核心辅以 Java、Python 实现和 proto 示例定义并包含 Makefile、configure、vcproj、sln 等构建工程文件及说明文档、测试用例便于在多种编译环境中落地。已有 216 人学习说明其在 protobuf 版本研究中具有一定参考价值。包内提供编译器相关源码、各语言运行库 API、用户指南与示例可帮助读者理解 .proto 消息定义、required/optional 字段语义以及序列化与反序列化流程也能为 gRPC 通信、日志记录、游戏数据交换等场景提供稳定版本参考和测试验证素材。1. 为什么一个 2014 年前后定版的 protobuf-2.6.0 源码包今天还有人翻出来前段时间接了个产线数据采集的活儿机器上跑的是编译链g 版本还停在 4.xC11 都开不全手头那个序列化库编译不过去最后能笑到最后的还是 protobuf-2.6.0。这类场景并不罕见老旧工控机、只能用 C98 的嵌入式工具链、被某个大数据组件锁死在 2.5.0 runtime 上的 Java 服务、需要读十几年前历史落盘 .pb 文件的迁移脚本。2.6.0 是 proto2 语法最后一批足够稳定、对老编译器足够宽容的版本自带 autotools 与 CMake 两套构建入口runtime 还能裁到 lite 级别塞进内存吃紧的设备也不心疼。它不适合拿来做新项目的序列化选型但作为“存量系统续命工具”它的位置很难被替代。下面按拆包、编译、写 .proto、踩坑、进阶的顺序讲透。2. 拆包先看三处src、cmake、vsprojects 决定了你怎么编译拿到一个源码包别急着./configure。protobuf 这类“一套 IDL 一套 runtime 一堆语言插件”的项目目录结构本身就写明了它的构建哲学先花五分钟看清楚能省掉后面两小时的报错排查。2.6.0 的包解开之后根目录下几个关键位置需要先认一遍后面不管走哪条编译路线都绕不开它们。2.1 源码树里真正干活的三块内容src/google/protobuf/是 runtime 本体序列化、反序列化、descriptor、反射、TextFormat、IO 流都在这里src/google/protobuf/compiler/是 protoc 的代码生成器按语言分子目录cpp、java、python 各一套src/google/protobuf/descriptor.proto是整个体系的自举点——protoc 自己的描述文件也是用 proto 写的这个文件的版本一变所有基于 descriptor 的插件立刻跟着崩。除src/还有三块外围目录值得记cmake/是 CMake 构建脚本的家注意 2.6.0 的 CMakeLists.txt 不在根目录而在cmake/子目录里vsprojects/是 Windows 的解决方案目录里面有一个extract_includes工程专门负责把散落在src/下的头文件摊平到一个 include 目录python/是 Python runtime 的独立分发目录带自己的 setup.py。搞清这三块的分工后面所有编译动作的“目标产物是什么”就清楚了你要的是libprotobuf库 protoc可执行文件 一份可以#include的头文件树。三者缺一工程就跑不起来。2.2 autotools 与 CMake 的取舍老环境为什么必须走 configure两条构建路线的差别不只是命令不同。autotools 走的是configure探测它会老老实实去试编译器支持哪些特性、系统有没有 zlib、能不能编出 shared library对 4.x 这种老 g 特别友好CMake 走的是显式配置判断更“硬”在老工具链上容易因为一个 feature 检测失败直接停下。我的经验分界线是编译器低于 g 4.8、或者要交叉编译到 ARM/Android走 autotools编译器 4.8 以上、或者要在 Windows 上出 Visual Studio 工程走 CMake。两条路最终产出的库 ABI 是一致的可以互相替换但别在同一台机器上混着装两次到同一个 prefix头文件和库版本对不上链接期会给你很难看的报错。维度autotoolsCMake入口位置根目录configurecmake/CMakeLists.txt老编译器兼容性好探测式一般需手动关特性交叉编译支持--host参数成熟需写 toolchain fileWindows 出工程基本不用主力方式卸载需自己维护文件清单同样需自己维护表里最后一行不是凑数。2.6.0 没有make uninstall装到/usr/local之后想换版本只能对着install_manifest.txt一条条删或者干脆装到独立 prefix。2.3 版本坐标2.6.0 能配什么、不能配什么这一节是选型判断的核心。protobuf 的版本兼容性有一条铁律线格式wire format跨版本稳定生成的代码不跨版本。意思是十年前的 .pb 二进制今天照样能解出字段但用 2.6.0 的 protoc 生成的 .pb.cc必须链接 2.6.0 的 libprotobuf差一点都不行。能力项2.6.0 的情况主力语法proto2required / optional / repeated / extensions / groupsproto3 语法不支持写syntax proto3无法按 proto3 语义处理内置输出语言C、Java、PythonJSON 互转runtime 不带要自己写或用 TextFormat 过渡C 标准要求C98 即可无需 C11构建系统autotools CMake 双套典型停留原因老编译器、老 Android NDK、被下游组件锁版本的 Java 服务“runtime 不带 JSON”这条要重点说。后来的 3.x 系列把 JSON 映射做进了官方库很多同学下意识以为 2.6.0 也有结果在代码里找JsonFormat找不到翻半天文档才发现压根不存在。在 2.6.0 上做前后端交互通常的做法是对外接口层用 JSON内部服务间通信用 protobuf中间手写一层 mapper或者用TextFormat::Printer输出一个类 JSON 的文本再自己转——后者只适合调试别上生产。还有一条容易被忽略optimize_for选项。在 .proto 里写option optimize_for LITE_RUNTIME;生成出来的 C 代码只依赖MessageLite会把 descriptor、反射、TextFormat 那一整块全部裁掉二进制体积能小一大截。代价是你失去了DebugString()和动态字段访问能力。移动端、嵌入式优先考虑它服务端老老实实留全量。3. 从源码到 protoc三套构建命令与关键参数这一章是可以直接抄作业的部分。三条路线Linux 上 autotools 编译、CMake 编译含 Windows、以及交叉编译到 ARM/Android。每条路线我都会标出“改哪个参数会得到什么结果”以及失败时先看哪一行日志。3.1 Linux 源码编译configure 的三个关键参数先解包、进目录然后不要急着 configure把 prefix 想清楚。装到/usr/local最省事但也最容易跟系统包管理器打架装到独立目录后面切换版本只要改一个-I和-L。tar -xzf protobuf-2.6.0.tar.gz cd protobuf-2.6.0 # --prefix装到独立目录避免污染系统 /usr/local # --disable-shared只出静态库部署时少一个 so 依赖 # CXXFLAGS 里的 -fPIC如果这个静态库最终要被塞进自己的 .so必须有 ./configure \ --prefix/opt/protobuf-2.6.0 \ --disable-shared \ CXXFLAGS-O2 -fPIC make -j$(nproc) make check # 跑一遍自带用例能过说明基础功能没问题 make install # 验证 /opt/protobuf-2.6.0/bin/protoc --version # 期望输出 libprotoc 2.6.0参数含义逐个说清--disable-shared关掉动态库生成libprotobuf.a和libprotoc.a静态链接的部署包在异构环境里最省心-fPIC不能省很多人编译期没事等到自己写一个 .so 去链接这个静态库时才蹦出relocation R_X86_64_32 against ... can not be used when making a shared object那时候回头重编更浪费时间。make check在老机器上可能要跑几分钟别跳过。它会跑一遍 wire format 的自测用例如果这一步挂了说明编译器在某个地方生成了不符合预期的代码后面拿这个库去解析历史数据就是灾难。失败时先看src/google/protobuf/*test.log报错行通常指向具体哪个模块。环境变量这一步也别忘装完把/opt/protobuf-2.6.0/bin加进 PATH否则调用的还是系统自带的老 protoc生成出来的代码版本跟你刚编的库对不上这是最高频的“灵异事件”来源。3.2 CMake 与 Windowscmake/ 子目录这个坑CMake 路线的第一个坑就在路径上。2.6.0 的根目录没有 CMakeLists.txt你得把源目录指到cmake/去cd protobuf-2.6.0 mkdir -p build cd build # 注意源目录是 ../cmake不是 .. cmake -G Unix Makefiles \ -DCMAKE_INSTALL_PREFIX/opt/protobuf-2.6.0 \ -Dprotobuf_BUILD_TESTSOFF \ -Dprotobuf_BUILD_SHARED_LIBSOFF \ ../cmake make -j$(nproc) make install-Dprotobuf_BUILD_TESTSOFF建议老机器上都开测试目标会显著拉长编译时间-Dprotobuf_BUILD_SHARED_LIBSOFF对应上面 autotools 的--disable-shared。如果你在执行cmake ../时报 “does not appear to contain CMakeLists.txt”那就是踩到子目录这个坑了。Windows 上分两条路。要出 Visual Studio 工程直接开vsprojects/protobuf.sln里面已经按 VS 版本分好了解决方案目录要出 NMake 或 Ninja 工程用 CMake生成器换成NMake Makefiles源目录同样是..\cmake。Windows 上还有一个必做动作把extract_includes工程跑一次它会把src/下分散的头文件复制到一个平坦的 include 目录。不跑这一步你在自己的工程里#include google/protobuf/message.h会一路找不到文件然后开始怀疑人生。3.3 交叉编译与 Android NDK两段式构建交叉编译是这个包最实用的场景之一也是最容易翻车的。核心原则一句话protoc 必须在构建机上原生跑libprotobuf 可以交叉编译两者版本必须一致。第一段先在构建机上编一个原生 protoc只装到临时目录mkdir -p /tmp/pb-host cd /tmp/pb-host tar -xzf /path/to/protobuf-2.6.0.tar.gz cd protobuf-2.6.0 ./configure --prefix/tmp/pb-host/out --disable-shared make -j$(nproc) make install第二段交叉编译目标平台的库。以 ARM 为例cd protobuf-2.6.0 make distclean # 上一段编过原生版本必须清干净否则配置缓存会串 ./configure \ --hostarm-linux-gnueabihf \ --prefix/opt/protobuf-arm \ --disable-shared \ --with-protoc/tmp/pb-host/out/bin/protoc make -j$(nproc) make install--with-protoc这个参数是关键。protobuf 的构建过程中要用 protoc 生成一部分内部 .pb.cc比如 descriptor 相关的交叉编译时构建机没法执行目标平台的 protoc必须显式告诉它“用那个原生版本”。不打这个参数编译到一半会报cannot execute binary file。Android NDK 的情形类似用独立 toolchain 或者 CMake 的 android toolchain file把-Dprotobuf_BUILD_TESTSOFF一定加上测试用例在 Android 上编不过。如果目标 App 只需要序列化能力不涉及反射和 TextFormat务必在 .proto 里加optimize_for LITE_RUNTIME产物能小很多——这一点在包体敏感的移动端是硬需求。4. 写 .proto、生成代码、跑序列化2.6.0 的语法边界编译出 protoc 只是第一步真正的日常活儿是写 .proto、生成代码、在业务里去序列化和反序列化。这一章把 2.6.0 的语法边界和三种语言的常用 API 接口梳理一遍重点标出那些“在新版本里能写、在这里不能写”的地方。4.1 proto2 语法在 2.6.0 里的边界先看一份覆盖常用特性的 .proto可以直接拿去跑// 注意2.6.0 不要写 syntax proto3按 proto2 语义走 package demo.device; // LITE 模式裁掉 descriptor 和反射移动端优先 option optimize_for LITE_RUNTIME; option java_package com.example.demo.device; option java_outer_classname DeviceProto; message DeviceReading { required string device_id 1; // 1~15 号字段编码后只占一个字节 tag required int64 ts_millis 2; optional double temperature 3 [default 0.0]; optional int32 status 4; repeated Sample samples 5; // 数值型 repeated 建议加 [packedtrue] repeated int32 raw 6 [packed true]; enum Level { LOW 0; MID 1; HIGH 2; } optional Level level 7 [default LOW]; extensions 100 to 199; // proto2 才有的扩展位 } message Sample { required int32 seq 1; optional float value 2; } extend DeviceReading { optional string firmware 100; // 业务侧扩展不用改主 message }几个必须记住的约束字段编号 115 编码后 tag 只占一个字节热字段放这里1900019999 是 protobuf 内部保留区写了会直接被 protoc 拒绝required在 2.6.0 里是硬约束缺字段会导致解析失败这是 proto2 与 proto3 最大的语义差异也是后面避坑章节的一个主角。[packed true]只对 repeated 的数值类型有意义它把连续的 varint 打包成一个 length-delimited 块能省掉每个元素一个字节的 tag。字符串和 message 类型的 repeated 加这个选项无效protoc 会忽略。4.2 protoc 三个输出目标与常用开关生成代码的命令不长但-I的写法决定了后面所有的 import 路径问题PROTOC/opt/protobuf-2.6.0/bin/protoc # C输出到 gen/cpp导入路径以 proto/ 为根 $PROTOC -I proto --cpp_outgen/cpp proto/demo/device.proto # Java一个 .proto 出一个外部类包名由 java_package 决定 $PROTOC -I proto --java_outgen/java proto/demo/device.proto # Python生成 device_pb2.py $PROTOC -I proto --python_outgen/python proto/demo/device.proto # 导出 descriptor set给动态解析和插件用 $PROTOC -I proto --descriptor_set_outgen/device.desc \ --include_imports proto/demo/device.proto-I指定的目录是 import 解析的根也是生成代码里相对路径的起点。上面写成-I proto且文件路径写proto/demo/device.proto生成的 C 头文件里 include 路径就是demo/device.pb.h如果你把-I写成-I .生成出来的路径会变成proto/demo/device.pb.h跟工程里的其他 include 全对不上。这个细节看着小实际是团队协作里最高频的“我这儿能编你那儿编不过”。--descriptor_set_out配--include_imports会把所有依赖的 .proto 描述一起打进二进制描述文件这是后面做动态解析的原料建议每次构建都顺手导一份当作“后悔药”存着——原始 .proto 丢了的项目靠这个文件能把结构还原出来。4.3 C 侧读写从 SerializeToString 到 SetTotalBytesLimitC 是最常被问的一块因为 2.6.0 的 API 和 3.x 有不少命名差异网上抄来的代码经常编不过。#include demo/device.pb.h #include fstream void write_one(const demo::device::DeviceReading msg, const std::string path) { std::string buf; // 返回 false 通常意味着 required 字段没填全 if (!msg.SerializeToString(buf)) { // 2.6.0 没有 IsInitialized 之外更细的报错先查 required return; } std::ofstream out(path.c_str(), std::ios::binary); out.write(buf.data(), static_caststd::streamsize(buf.size())); } bool read_one(const std::string path, demo::device::DeviceReading* msg) { std::ifstream in(path.c_str(), std::ios::binary); // 注意 2.6.0 的 SetTotalBytesLimit 需要两个参数 google::protobuf::io::IstreamInputStream raw(in); google::protobuf::io::CodedInputStream coded(raw); coded.SetTotalBytesLimit(512 * 1024 * 1024, 256 * 1024 * 1024); return msg-ParseFromCodedStream(coded) msg-IsInitialized(); }三个点解释清楚。第一SerializeToString返回 false 基本只有一种情况required字段缺失2.6.0 不会告诉你缺哪个得靠IsInitialized()加上InitializationErrorString()去定位。第二SetTotalBytesLimit在这个版本里是双参数签名总量上限、告警阈值网上很多只传一个参数的示例是更早版本的写法直接抄会编译失败。第三用CodedInputStream包一层而不是直接ParseFromIstream是为了能显式控制上限——默认上限在大消息场景下不够用这是下一章的重点坑。Java 和 Python 侧相对直接Java 用DeviceReading.parseFrom(byte[])和toByteArray()注意 2.6.0 生成的类继承的是GeneratedMessage而不是后来的GeneratedMessageV3Python 用DeviceReading.FromString(data)和SerializeToString()模块从包自带的python/目录安装别和系统里的新版 pip 包混用。5. 避坑版本错配、高版本编译器与大消息的五个翻车现场这一章全是血泪。下面五条都是我在实际项目里撞过的按“现象 → 原因 → 解决”写遇到同款直接对号入座。5.1 坑一GCC 高版本编 2.6.0 报头文件缺失现象在 GCC 6 以上的机器上make报error: numeric_limits is not a member of std或者ptrdiff_t has not been declared位置都在src/google/protobuf/下的头文件里。原因2.6.0 的代码是按老编译器的“头文件传递包含”习惯写的某些标准头比如limits、cstddef依赖别的头间接带进来。新版本 GCC 清理了这类隐式包含于是原本能过的代码编不过了。解决最省事的办法是在 configure 时全局补头不动源码./configure --prefix/opt/protobuf-2.6.0 \ CXXFLAGS-O2 -fPIC -include limits -include cstddef-include是 GCC 的强制预包含开关等价于在每个源文件顶部插一行#include。如果还报-Werror相关的 deprecated 警告std::auto_ptr这类加-Wno-deprecated-declarations -Wno-error压掉。别去改源码改一次后面每次重新解包都要再来一遍。5.2 坑二生成代码与 runtime 版本对不上现象编译期报#error This file was generated by a newer version of protoc which is incompatible with your Protocol Buffer headers或者链接期一堆undefined reference to google::protobuf::internal::...。原因.pb.cc 是某个版本的 protoc 生成的链接的却是另一个版本的 libprotobuf。生成代码里有PROTOBUF_VERSION的编译期断言2.6.0 对应 2006000头文件版本低了直接编译失败侥幸编过了链接时符号名或签名不一致照样炸。解决把“生成器版本”和“runtime 版本”绑成一个整体来管。工程里固化三件事protoc 的绝对路径、libprotobuf 的 prefix、生成代码的时间戳。用脚本强制检查# 每次构建前校验版本不一致直接退出 EXPECTlibprotoc 2.6.0 ACTUAL$(${PROTOC} --version) if [ $ACTUAL ! $EXPECT ]; then echo protoc 版本不符: $ACTUAL ! $EXPECT; exit 1 fi # 顺带检查运行时头文件里的版本宏 grep -m1 define GOOGLE_PROTOBUF_VERSION \ /opt/protobuf-2.6.0/include/google/protobuf/stubs/common.h第二段输出应该是 2006000。这个检查加进 CI 只要十几行能挡掉后面 90% 的“在我机器上是好的”。5.3 坑三Java 侧被下游组件锁版本现象服务启动或首次反序列化时抛NoClassDefFoundError: com/google/protobuf/GeneratedMessageV3或者NoSuchMethodError指向com.google.protobuf包下的某个方法。原因classpath 里同时存在多个 protobuf-java 版本。你自己的代码用 2.6.0 生成某个下游依赖悄悄拉进了 3.x 的 jarMaven 的最近优先原则选中了 3.x2.6 生成的类在 3.x runtime 上找不到对应的父类反过来如果下游拉的是更老的 2.5.0新生成的调用的方法在老 runtime 里不存在就是NoSuchMethodError。这类冲突在 20132015 年发布的那批大数据组件里极其常见它们往往把 protobuf 当成内部实现细节直接打进自己的 jar。解决先定位再隔离。# 第一步看清谁把 protobuf 拉进来的 mvn dependency:tree -Dincludescom.google.protobuf # 第二步对着报错的类看它到底引用了哪个符号 javap -c -p target/classes/com/example/demo/device/DeviceProto.class | grep protobuf定位到冲突来源后优先做排除把传递依赖里的 protobuf 剔掉如果对方把 protobuf 打进自己的 jar 里shade 过但没 relocate排除不掉就只剩重定位一条路——用 shade 插件把 protobuf 的包名整体改掉或者干脆把 protobuf 相关的类加载做隔离。别指望“升级到 3.x 一劳永逸”存量组件的线格式虽然兼容但生成代码不兼容升级等于把所有 .proto 重新生成一遍再全量回归。5.4 坑四大消息解析直接失败日志只有一行 too large现象解析一个几十兆的消息ParseFromString返回 false日志里只有一行Protocol message was too large. May be malicious.看不出更多信息。原因CodedInputStream对单个流有默认的总字节上限2.6.0 时代这个默认值远小于很多业务的实际消息体量。一旦超过解析直接失败而且不会告诉你是哪个字段撑爆的。解决显式调大上限并顺手把递归深度也设一下嵌套过深的恶意数据同样会把你打挂google::protobuf::io::CodedInputStream coded(raw); // 参数一总字节上限参数二超过该值时打告警日志 coded.SetTotalBytesLimit(512 * 1024 * 1024, 256 * 1024 * 1024); // 默认递归深度上限 100嵌套层级深的业务要放开 coded.SetRecursionLimit(200);调大之前先想清楚这个消息真的需要一次性读进内存吗更好的做法是把大消息拆成多条小消息流式写、流式读用WriteVarint32写长度前缀读端先读长度再定界。上限只是止血拆包才是治本。5.5 坑五required字段导致老数据解析失败现象新版本 .proto 给某个 message 加了一个required字段上线后读历史数据全部失败ParseFromString返回 false。原因proto2 的required是解析期强校验历史数据里没有这个字段解析直接被判为不完整消息。这个坑的杀伤力在于它是“上线即炸”而且影响的是所有存量数据不是新写入的数据。解决业务 message 里永远不要用required一律用optional加业务层校验。如果历史包袱已经在了只能做兼容处理保留老字段为optional新建一个 v2 message 承载强约束读取时先按老 schema 解再转换。这条经验是从 proto2 迁移到 proto3 时最值钱的一条proto3 干脆把required从语法里删掉了不是没有原因的。6. 进阶用 descriptor 做免编译的字段读取有时候你手上只有一堆历史 .pb 二进制和一个 .desc 描述文件原始 .proto 早就丢了或者你需要在不停机、不重新编译的情况下按字段名取出某个值。这种场景下2.6.0 自带的动态消息能力就非常值钱DynamicMessageFactory配合DescriptorPool可以在运行时按描述文件构造消息对象完全不依赖生成的 C 类。先确保你手里有描述文件前面--descriptor_set_out那一步的产物然后按下面的骨架写#include google/protobuf/descriptor.pb.h #include google/protobuf/dynamic_message.h #include google/protobuf/descriptor_database.h #include fstream const google::protobuf::Descriptor* load(const std::string desc_path, const std::string msg_name) { std::ifstream in(desc_path.c_str(), std::ios::binary); google::protobuf::FileDescriptorSet fds; fds.ParseFromIstream(in); // SimpleDescriptorDatabase 接管描述文件注意它不负责释放 fds static google::protobuf::SimpleDescriptorDatabase db; for (int i 0; i fds.file_size(); i) db.Add(fds.file(i)); static google::protobuf::DescriptorPool pool(db); return pool.FindMessageTypeByName(msg_name); // 例如 demo.device.DeviceReading }拿到Descriptor之后用DynamicMessageFactory::GetPrototype()取到原型New()出一个可读写的消息对象再配合Reflection按字段名取值google::protobuf::DynamicMessageFactory factory; const google::protobuf::Message* proto factory.GetPrototype(desc); google::protobuf::Message* msg proto-New(); msg-ParseFromString(raw_bytes); // 失败时先怀疑 required const google::protobuf::Reflection* refl msg-GetReflection(); const google::protobuf::FieldDescriptor* f desc-FindFieldByName(temperature); if (f refl-HasField(*msg, f)) { double t refl-GetDouble(*msg, f); // 按字段类型选对应 Get 方法 } delete msg; // prototype 归 factory 管实例要自己删两个必须注意的点SimpleDescriptorDatabase和DescriptorPool都声明成 static是为了避免生命周期问题——它们内部持有指针一旦提前析构后续所有Descriptor*全部悬空症状是随机崩溃极难排查。另外factory.GetPrototype()返回的对象归工厂所有不要 deleteNew()出来的实例归你必须自己释放。这套做法的边界也要说清optimize_for LITE_RUNTIME生成的代码和对应的描述文件里没有完整的反射信息动态解析拿不到字段元数据。要玩动态.proto 里就不能开 lite。这是个二选一很多人在移动端裁完体积回头想做动态工具才发现路被自己堵死了。还有一个我常备的排查手段protoc --decode_raw。当你连描述文件都没有、只有一段二进制时它能按线格式硬解出一层结构字段名显示为数字编号虽然不完美但足以判断这是不是 protobuf、有几个字段、哪个字段是嵌套消息。我一般先用它扫一眼再决定值不值得去还原完整 schema。从那以后我每次接存量 protobuf 项目都会先做三件事确认 protoc 和 runtime 版本并写成脚本卡在 CI 第一步、导出一份--include_imports的描述文件存档、把业务 message 里的required全部排查一遍改成optional。这三步加起来不到半小时省下的是后面几天的通宵。包里的 autotools 和 CMake 两套构建文件都在解压之后按第 3 章的顺序走一遍老机器上也能顺利跑起来。希望帮到你。本文还有配套的精品资源点击获取