简介：OpenSSL 3.2.0 x64 Windows 静态库 release 版面向需要在 C/C++ 工程中集成 TLS/SSL、证书处理与密码学能力的开发者，适合桌面软件、服务端通信模块及安全类课程实验等场景。压缩包共 995 个文件、约 15.14MB，核心包含 libssl.lib 和 libcrypto.lib 两个静态库，以及 openssl 目录下的 141 个头文件，覆盖 SSL/TLS、EVP、X.509、ASN.1、EC 等常用接口模块；同时附带 844 个 html 文档和少量 png、perl、exe 辅助文件，可用于离线查阅 API 说明、核对头文件依赖与验证工具环境。该版本已通过 VS2019 调用测试，采用 no-shared、no-asm 的 x64 配置，静态链接方式能减少运行时 DLL 依赖，便于把库直接纳入既有工程。已有 623 人学习下载，读者可获得可直接引用的库文件、完整头文件与离线文档，减少自行编译和排查链接错误的成本，把精力放在业务集成、接口调用和问题定位上；对初学者可作为可运行的依赖基线，对已有项目也便于快速替换升级。

1. 静态库接入的真实起点：不是 include 找不到，是符号对不上

上周有人把OpenSSL 3.2.0 x64 Windows 静态库 release 版本的压缩包拖进 VS 工程，头文件路径配好了，#include <openssl/evp.h>也不报红，一编译链接器甩出四十多条 LNK2019，__imp_socket、OPENSSL_init_crypto、EVP_CIPHER_CTX_new全在里面。多数人第一反应是库坏了或者架构不对，其实九成情况是链接姿势的问题：静态库不是把 dll 换了个后缀，它把整个 crypto 实现连同对系统 API 的依赖一起塞进 exe，链接器需要你把该给的东西一次给全。

这份资源解决的就是「不想在客户机器上多带两个 dll、不想被 PATH 和版本串味搞死」的诉求。适合做单文件分发工具、做内网离线部署、做安装包里不能有额外二进制的场景。下面从产物辨认一路讲到 provider 加载，中间所有命令和参数都可以直接抄。

2. 静态库与导入库：x64 工程里先认清 libcrypto.lib 是哪一种

2.1 同名文件，两种完全不同的东西

Windows 上libcrypto.lib这个名字被复用了两次。动态库方案里它是导入库，里面只有几十个跳转桩，真正的代码在libcrypto-3-x64.dll；静态库方案里它是实打实的归档文件，几十个 obj 打包在一起，链接完 exe 体积直接涨十几兆。名字一样，用途完全相反，混用的后果是链接期看着能过、运行期找不到 dll 直接退出，或者反过来符号重复定义。

最省事的辨认方式是看体积和伴随文件。导入库通常几百 KB，同目录下必然躺着libcrypto-3-x64.dll；静态库普遍在 10 MB 量级，目录里没有 dll。我一般还会用dumpbin /headers libcrypto.lib | findstr "machine"确认架构，输出8664才是 x64，14C是 x86，AA64是 ARM64。这个检查做一次，能省掉后面半小时的自我怀疑。

还有一层要分清：/MD编出来的库和/MT编出来的库不能混。两者引用不同的 CRT 符号，/MT工程链接/MD库会报 LNK4098 defaultlib 冲突；即便用/NODEFAULTLIB强行压过去，也会在 exe 里出现两套堆管理，跨模块free的时候崩得毫无规律。静态库把这条坑放大了一倍，因为库代码和你的代码最终在同一个进程空间里共享同一个 CRT 实例，一旦不匹配，问题不会在链接期暴露干净。

2.2 资源包里应该有哪些东西

一个能直接用的 3.2.0 静态库发行目录，结构大致是这样：

如果对方只给了lib和include，没有bin/openssl.exe，验签和自检会麻烦一些，得自己写个小程序打印版本号。如果连ossl-modules都没有，说明打包时没有启用模块化 provider，只能用 default provider 里那批算法，MD4、RC4、DES 这类老算法会直接拿不到。

2.3 什么情况下该选静态库

选型判断别拍脑袋，看三条。第一条是分发形态：要求绿色解压即用、不允许安装运行库、不允许改 PATH，静态库是唯一解。第二条是版本锁定：内网机器上可能已经存在别的软件带的libcrypto-3-x64.dll，版本还各不相同，动态链接会被先搜到的那个抢走，静态链接没有这个风险。第三条是体积容忍度：一个只做 SHA-256 和 AES 的小工具，静态链接后 exe 从 200 KB 涨到 5 MB 左右，链接器会做函数级裁剪，用不到的算法不会被拉进来，实际增幅比想象中小。

反过来，如果工程本身就是插件形态（dll 被宿主加载）、或者多个模块要共享同一份 OpenSSL 上下文、或者需要 FIPS 合规，静态库就不合适了。FIPS provider 有明确的模块边界要求，静态链接进去再声称合规是站不住的。

提示：拿到包先别急着改工程属性，用dumpbin /symbols libcrypto.lib | findstr "OPENSSL_init_crypto"看一眼符号在不在。在，说明库是好的，问题在你的链接配置。

3. 接进 MSVC 工程：include 路径、/MD 对齐与系统库补齐清单

3.1 目录布局与三种包含方式

我习惯把解压出来的东西放在解决方案同级的一个third_party/openssl-3.2.0-x64目录下，然后在工程属性里用宏引用，避免路径写死导致换机器就崩：

// 工程属性 → C/C++ → 附加包含目录 $(SolutionDir)third_party\openssl-3.2.0-x64\include // 工程属性 → 链接器 → 附加库目录 $(SolutionDir)third_party\openssl-3.2.0-x64\lib

头文件引用的写法有两种风格。用#include <openssl/evp.h>是官方推荐姿势，要求包含目录指向include的父级；用#include "openssl/evp.h"更省事，包含目录直接指到include。两种都行，但一个工程里必须统一，混着写迟早出现同个头文件被两个不同路径包含、结构体定义重复的怪事。

代码里用#pragma comment(lib, ...)把链接项写在源文件里，比在工程属性里挨个添加更不容易漏，也方便把某段功能整体搬走：

// openssl_link.h —— 统一声明，避免每个 .cpp 里重复写 #pragma comment(lib, "libcrypto.lib") #pragma comment(lib, "libssl.lib") // 只用到加密算法时可以删掉 // OpenSSL 自身依赖的系统库，缺一个就是一批 LNK2019 #pragma comment(lib, "ws2_32.lib") // socket，BIO 走网络时必需 #pragma comment(lib, "crypt32.lib") // Windows 证书存储、PKCS#12 #pragma comment(lib, "bcrypt.lib") // BCryptGenRandom，3.x 的 RNG 种子源 #pragma comment(lib, "advapi32.lib") // 注册表、部分随机源 #pragma comment(lib, "user32.lib") // 老路径里的 UI 相关调用 #pragma comment(lib, "gdi32.lib") // 同上，边界场景

这段说明两件事：一是libssl依赖libcrypto，链接器对静态库的顺序敏感，libssl.lib必须写在libcrypto.lib前面，否则会出现「libssl 里的函数找不到 libcrypto 里的实现」这类反直觉报错。二是六个系统库不是凑数，bcrypt.lib在 3.x 上是硬依赖——如果你的 exe 在启动阶段就崩在OPENSSL_init_crypto内部，先查这个。

3.2 运行库选项必须逐项对齐

编译选项里最容易被忽略的是「代码生成 → 运行库」。静态库是用某个具体的 CRT 编出来的，你的工程必须用同一个。检查路径：工程属性 → C/C++ → 代码生成 → 运行库，Release 配置下要么是/MD（多线程 DLL），要么是/MT（多线程静态）。

怎么知道库是哪种？dumpbin /directives libcrypto.lib | findstr "DEFAULTLIB"能看到它引用了MSVCRT还是LIBCMT。前者对应/MD，后者对应/MT。这一步不做，后面所有报错都是在错误前提上推理。

Release 版本还有两个配套项不能忘：C/C++ → 优化开/O2，C/C++ → 代码生成 → 启用增强指令集保持默认（/arch:SSE2及以上），以及C/C++ → 语言 → 符合模式设为「否」——OpenSSL 的头文件里有几处写法在/permissive-下会报 C4996 级别的挑剔警告。这些不影响功能，但会让第一次编译的输出看起来很吓人。

3.3 一段最小验证代码

工程配好之后别急着写业务，先跑一段二十行以内的自检，确认库真的链进去了：

// selfcheck.c —— 编译成控制台程序，Release x64 #include <stdio.h> #include <string.h> #include <openssl/opensslv.h> #include <openssl/crypto.h> #include <openssl/evp.h> int main(void) { /* 1. 版本串：确认链接的是 3.2.0，而不是系统里别的版本 */ printf("runtime : %s\n", OpenSSL_version(OPENSSL_VERSION)); printf("built on: %s\n", OpenSSL_version(OPENSSL_BUILT_ON)); /* 2. 跑一次 SHA-256，验证 EVP 层可用 */ unsigned char md[EVP_MAX_MD_SIZE]; unsigned int mdlen = 0; EVP_MD_CTX *ctx = EVP_MD_CTX_new(); if (ctx == NULL) { printf("ctx alloc failed\n"); return 1; } EVP_DigestInit_ex(ctx, EVP_sha256(), NULL); EVP_DigestUpdate(ctx, "openssl-3.2.0", 13); EVP_DigestFinal_ex(ctx, md, &mdlen); EVP_MD_CTX_free(ctx); printf("sha256 : "); for (unsigned int i = 0; i < mdlen; i++) printf("%02x", md[i]); printf("\n"); return 0; }

逻辑说明：第一段拿OpenSSL_version()返回运行期版本，这是判断「链进来的到底是谁」最直接的手段，比看工程属性可靠。第二段走一遍完整的 EVP 摘要流程，EVP_MD_CTX_new分配上下文、EVP_DigestInit_ex绑定算法、EVP_DigestUpdate喂数据、EVP_DigestFinal_ex取结果、EVP_MD_CTX_free释放。这套五步式是 3.x 里所有 EVP 操作的通用骨架，后面加解密、签名都是同一套模式换函数名。

参数说明：EVP_sha256()返回的是算法描述符，3.x 里它内部会去 default provider 里查实现，查不到就返回 NULL——这也是为什么 provider 没配好时，EVP_DigestInit_ex会失败但不会崩。EVP_MAX_MD_SIZE是编译期常量 64，够放下任何摘要输出，别自己写 32。mdlen用unsigned int而不是int，是因为EVP_DigestFinal_ex的第三个参数签名就是unsigned int*。

跑通之后把输出贴出来对一下：版本串应该是OpenSSL 3.2.0开头，SHA-256 结果对空串以外任何输入都该是 64 个十六进制字符。两样都对，说明库、头文件、CRT 三者的匹配关系是成立的，可以往下走了。

4. EVP 实战：AES-256-GCM 加密与 RSA 签名的静态链接写法

4.1 为什么 3.x 必须走 EVP，不能再用 AES_encrypt

OpenSSL 3.0 最大的结构变化是把算法实现从「编译进去的函数」变成了「provider 注册的模块」。AES_encrypt、RSA_public_encrypt、SHA256_Init这批低层 API 被标了 deprecated，它们在 3.x 里通常还能编过，但会走一条内部垫片路径，而且在某些 provider 配置下直接返回失败。更要命的是，低层 API 不支持硬件加速的自动选择，AES-NI 用不上，性能差一个数量级。

EVP 这层的价值在于「算法名字符串 → 实现」的间接寻址。你写EVP_aes_256_gcm()，实际实现可能是 AES-NI 版本、也可能是 ARMv8 的 crypto 扩展版本，由 provider 决定，业务代码不关心。这种间接性在静态链接下有一个副作用：算法描述符是运行期构造的，链接器看不到引用关系，--gc-sections或/OPT:REF有可能把没被显式引用的实现裁掉。实践中 3.2.0 的 Windows 静态库对常用算法做了保留，不会出问题，但如果发现某个冷门算法（比如 Camellia）在 Release 下返回 NULL 而 Debug 下正常，第一个怀疑对象就是链接器裁剪，关掉/OPT:REF验证一下即可。

4.2 AES-256-GCM 加密与认证标签

GCM 是带认证的加密模式，输出密文的同时产出一个 16 字节 tag，解密时必须拿着同一个 tag 一起验证。静态库下这段代码不需要任何额外初始化，直接调：

#include <openssl/evp.h> #include <string.h> /* 返回 0 成功，-1 失败。out 缓冲区需 >= inlen + 16 */ int aes_gcm_encrypt(const unsigned char *key, /* 32 字节 */ const unsigned char *iv, /* 12 字节，推荐 */ const unsigned char *aad, int aadlen, const unsigned char *in, int inlen, unsigned char *out, int *outlen, unsigned char *tag) /* 16 字节 */ { EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new(); int len = 0, total = 0; if (!ctx) return -1; /* 第一步：绑定算法，此时还不给 key/iv */ if (1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, NULL, NULL)) goto err; /* 第二步：设置 IV 长度。GCM 默认 12，改别的长度必须显式声明 */ if (1 != EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_AEAD_SET_IVLEN, 12, NULL)) goto err; /* 第三步：这一遍才真正灌 key 和 iv */ if (1 != EVP_EncryptInit_ex(ctx, NULL, NULL, key, iv)) goto err; /* 第四步：附加认证数据，不加密但要参与 tag 计算 */ if (aadlen > 0) { if (1 != EVP_EncryptUpdate(ctx, NULL, &len, aad, aadlen)) goto err; } /* 第五步：加密正文 */ if (1 != EVP_EncryptUpdate(ctx, out, &len, in, inlen)) goto err; total = len; /* 第六步：收尾，GCM 无填充，这里通常输出 0 字节 */ if (1 != EVP_EncryptFinal_ex(ctx, out + total, &len)) goto err; total += len; /* 第七步：取认证标签，必须放在 Final 之后 */ if (1 != EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_AEAD_GET_TAG, 16, tag)) goto err; *outlen = total; EVP_CIPHER_CTX_free(ctx); return 0; err: EVP_CIPHER_CTX_free(ctx); return -1; }

逻辑说明：这个函数严格按 GCM 的初始化顺序写。EVP_EncryptInit_ex被调用了两次，第一次只绑算法、第二次才给密钥，这是为了中间插入SET_IVLEN。很多人把 key/iv 一次性塞进第一次调用，然后发现改 IV 长度不生效，就是顺序错了。

参数说明：key 必须 32 字节（AES-256），iv 推荐 12 字节（GCM 的原生长度，非 12 字节会触发内部 GHASH 预处理，慢且容易出错）。aad 是附加认证数据，比如协议头、序列号，它不进入密文但会改变 tag，解密端必须提供完全相同的 aad 才能验证通过。tag 固定 16 字节，短 tag（8 字节）虽然协议支持，但会削弱认证强度，不建议。

解密端的写法是镜像：EVP_DecryptInit_ex→SET_IVLEN→ 灌 key/iv → 喂 aad →EVP_DecryptUpdate解正文 → 在EVP_DecryptFinal_ex之前用EVP_CTRL_AEAD_SET_TAG把 tag 塞进去。顺序反了会直接返回 0，看起来像密钥错，实际是时序错。

4.3 RSA 签名与验签

3.x 里 RSA 签名统一走EVP_DigestSign，一个函数族覆盖 RSA、ECDSA、Ed25519。下面这段用的是 PEM 格式的私钥文件，读文件那部分省略，重点在签名流程：

#include <openssl/evp.h> #include <openssl/pem.h> /* 用 EVP_PKEY 对 data 做 SHA-256 + RSA-PKCS1 签名，输出写入 sig，长度写 siglen */ int rsa_sign(EVP_PKEY *pkey, const unsigned char *data, size_t datalen, unsigned char *sig, size_t *siglen) { EVP_MD_CTX *mctx = EVP_MD_CTX_new(); int ok = -1; if (!mctx) return -1; /* 第一段：绑定 pkey 和摘要算法 */ if (1 != EVP_DigestSignInit(mctx, NULL, EVP_sha256(), NULL, pkey)) goto done; /* 第二段：先问一次签名长度，RSA 2048 是 256 字节 */ if (1 != EVP_DigestSign(mctx, NULL, siglen, data, datalen)) goto done; /* 第三段：真正签名 */ if (1 != EVP_DigestSign(mctx, sig, siglen, data, datalen)) goto done; ok = 0; done: EVP_MD_CTX_free(mctx); return ok; }

逻辑说明：EVP_DigestSign被调了两次，第一次传NULL作为输出缓冲，作用是探长度；第二次才真写。这个「两段式」在 RSA 上看起来多余（长度固定等于模长），但同一份代码换到 ECDSA 上就必须这么做，因为 ECDSA 签名长度不固定。

参数说明：EVP_DigestSignInit的第二个参数是EVP_PKEY_CTX **，一般传 NULL，需要设 padding 模式（比如 PSS）时才接出来用EVP_PKEY_CTX_set_rsa_padding。第三个参数决定摘要算法，选EVP_sha256()意味着签名内部会先对 data 做一次 SHA-256，你的 data 是原文不是摘要值——这一点和RSA_sign那套低层 API 的语义不同，别搞混。

验签用EVP_DigestVerifyInit/EVP_DigestVerify，返回值 1 表示通过，0 表示签名不匹配，负数表示内部错误。把 0 和负数分开处理很重要：0 是数据问题，负数是配置问题（比如公钥类型不对、provider 缺失），两者的排查方向完全不同。

4.4 证书链验证在静态库下的额外步骤

动态链接时 OpenSSL 会从系统证书存储里找根证书，静态链接下这条路径依然能用，但需要显式打开。做法是：

X509_STORE *store = X509_STORE_new(); X509_STORE_set_default_paths(store); /* 加载 Windows 证书存储 */ /* 或者离线场景下喂一个 PEM bundle */ /* X509_STORE_load_file(store, "ca-bundle.pem"); */

离线部署的机器经常没有更新过根证书，X509_STORE_set_default_paths会返回成功但里面是空的，验证时给出「unable to get local issuer certificate」。这种情况只能随包带一份 CA bundle，用X509_STORE_load_file显式加载。这是静态库部署里最常见的「本地能跑、客户机器不行」的原因之一。

5. 避坑与排查：从 LNK2019 到启动期崩溃的定位顺序

5.1 现象：一屏 LNK2019，全是__imp_开头的符号

原因几乎固定：漏了系统库。__imp_socket、__imp_WSAGetLastError说明缺ws2_32.lib；__imp_BCryptGenRandom说明缺bcrypt.lib；__imp_CertOpenStore说明缺crypt32.lib。3.x 把这些依赖藏得比较深，头文件里看不到，要到链接期才暴露。

解决顺序：先看第一个报错符号，不要看最后一个。链接器是按顺序解析的，第一个未解析符号往往指向真正缺失的那个库，后面的都是它的连锁反应。把__imp_前缀去掉，去微软文档里查这个 API 属于哪个库，加进去，重新链接。别一次性把能想到的库全加上，那样会掩盖真正的问题，下次换台机器又得重来一遍。

5.2 现象：LNK4098 defaultlib 'MSVCRT' conflicts with use of other libs

原因：运行库不匹配。你的工程用/MT，库是/MD编的，或者反过来。链接器会挑一个用，然后警告你另一半可能出问题，实际运行时的表现是随机的堆损坏。

解决：先用dumpbin /directives确认库的 CRT 类型，再把工程属性里的运行库改成一致的。改不了库（比如只有一个发行包），那就改工程。如果两边都改不了，用/NODEFAULTLIB:MSVCRT强行压制是最后手段，压完必须跑一遍内存密集的测试，因为两套堆共存的问题不会在编译期暴露。

5.3 现象：Debug 能跑，Release 一启动就崩在OPENSSL_init_crypto

原因通常不是库的问题，是配置文件。3.x 在初始化时会去找openssl.cnf，查找顺序包括OPENSSL_CONF环境变量、编译期写死的OPENSSLDIR、当前工作目录。Release 版本如果被打包成单文件或者换了工作目录，找不到配置文件时行为会跟 Debug（在工程目录下运行、旁边就有 cnf）不一样。

解决：第一，显式设置OPENSSL_CONF环境变量指向随包的 cnf；第二，如果压根不需要自定义配置，在main最开头调一次OPENSSL_init_crypto(OPENSSL_INIT_NO_LOAD_CONFIG, NULL)，跳过配置文件加载，让 default provider 走内建默认值。第二种做法在工具类程序里更常见，代价是用不了 cnf 里的自定义 provider 配置。

5.4 现象：OSSL_PROVIDER_load(NULL, "legacy")返回 NULL

原因：找不到模块。静态库发行包里ossl-modules目录默认不会被 exe 自动定位，OpenSSL 会去OPENSSLDIR/modules找，那个路径多半是编译时的绝对路径，换机器就失效。

解决：设置OPENSSL_MODULES环境变量指向 exe 同级的ossl-modules目录，或者在代码里OSSL_PROVIDER_set_default_search_path(NULL, ".\\ossl-modules")。还有一个更彻底的办法：如果只需要 MD4、RC4 这类算法，考虑在编译期就用enable-legacy把 legacy provider 静态编进去，运行时不用加载模块，OSSL_PROVIDER_load会命中内建版本。这个改动需要在源头重新编译，发行包改不了。

5.5 现象：跨模块传unsigned char*后，释放时崩溃

原因：CRT 堆不一致。静态库把 OpenSSL 的分配器编进了 exe，如果某个 dll 插件也静态链接了同一份库，两个模块各有各的堆，A 模块OPENSSL_malloc出来的指针在 B 模块OPENSSL_free，行为未定义。

解决：边界上不要传 OpenSSL 分配的裸指针。要么在模块内部转换成malloc分配的缓冲区再传出，要么提供一个「在哪个模块分配就在哪个模块释放」的包装函数。这条在插件化架构里是血泪经验，静态链接的便利性和内存边界的安全性需要权衡。

6. 进阶自检：版本、provider 与 openssl.cnf 的一次性验真

包接进工程、跑通第一个 demo 之后，我习惯再做一次「验真」，把这套静态库的实际能力和边界摸清楚，避免上线后才发现某个算法不可用。

第一步是算法清单核对。用随包的openssl.exe（如果有）执行openssl list -digest-algorithms和openssl list -cipher-algorithms，把输出存成文本。然后在你自己的 exe 里用EVP_MD_fetch(NULL, "SM3", NULL)逐个探测，返回非 NULL 才算真的可用。这两份结果对不上，说明运行环境的 provider 配置和命令行工具的不一样，需要查OPENSSL_MODULES。

第二步是 provider 枚举。3.2.0 默认带 default 和 base 两个内建 provider，legacy 和 fips 需要额外模块。写个小循环：

#include <openssl/provider.h> OSSL_PROVIDER *p = NULL; while ((p = OSSL_PROVIDER_do_all(NULL, NULL)) != NULL) { /* 实际用 OSSL_PROVIDER_available 逐个查 */ } /* 更直接的做法 */ const char *names[] = {"default", "base", "legacy", "fips", NULL}; for (int i = 0; names[i]; i++) printf("%-8s : %s\n", names[i], OSSL_PROVIDER_available(NULL, names[i]) ? "yes" : "no");

OSSL_PROVIDER_available只查不加载，适合做启动自检；真要用于业务得用OSSL_PROVIDER_load并保存返回值。这段输出能一眼看出你的包是「精简版」还是「全量版」，比翻文档快。

第三步是配置文件的可控性。把openssl.cnf放在 exe 同级，用OPENSSL_CONF=.\openssl.cnf显式指定，然后故意在里面写一行错误的 provider 配置，看程序是否按预期报错。能按预期报错，说明配置路径是通的；如果毫无反应，说明程序压根没读到这个文件，后面所有基于 cnf 的调优都是空谈。

第四步是升级路径的对齐。3.2.0 属于功能版本，不是长期支持分支，官方维护窗口是有限的。工程如果只是短期交付，用 3.2 尝鲜没问题；如果是需要维护三五年的产品，建议把接口层收敛在 EVP 上，将来换到 LTS 分支时只需要替换 lib 和 include，业务代码一行不动。我见过有人在 1.1.1 上写了一堆低层 API 调用，升 3.x 时整片重写，代价远超当初省下的那点封装功夫。

最后说个我自己的习惯：每接一个新版本的 OpenSSL 静态库，不管对方说得多好听，我都会先跑一遍selfcheck.c加OSSL_PROVIDER_available的探测，把版本串、SHA-256 结果、provider 清单三项写进项目 README 的「依赖基线」一节。后面任何人报「本地能跑服务器不行」，先对这三项，八成的环境问题在这三步之内就能定位。从那以后我每次换库都强制走一遍这个验真流程，省下的排查时间比写这段代码的时间多得多。希望帮到你。

本文还有配套的精品资源，点击获取