简介：本资源为 gRPC 1.28 在 Windows 平台配合 Visual Studio 2015 的 C++ 编译库，面向需要在 Windows 下开发跨语言微服务通信的 C++ 工程师与学习者。它解决了在旧版 VS 环境中搭建 gRPC 与 protobuf 3.11 开发环境的繁琐问题，省去自行编译依赖的步骤。压缩包共 472 个文件，约 24.47MB，以 387 个 h 头文件、34 个 lib 静态库、14 个 cmake 构建脚本、12 个 proto 接口定义及 11 个 exe 工具为主，另含少量 dll、pc 与 pem 文件，覆盖头文件引用、库链接、CMake 集成与证书配置等环节。已有 998 人学习下载。借助其中的库文件与构建脚本，读者可快速完成服务端 ServerBuilder 监听、客户端 Channel 与 Stub 调用，并理解 protoc 将 .proto 编译为 C++ 代码的完整流程，适合作为分布式系统入门与工程集成的参考。
1. gRPC 1.28 在 Windows 上用 VS2015 编译 C++ 库：一条被低估的产线级路径
如果你手上维护的是 VS2015 时代的 C++ 工程，又需要把服务间通信从自研 socket 换成 gRPC，那 gRPC 1.28 这个版本大概率是你绕不开的节点。原因很直接：再往后的版本对 MSVC 工具集的要求逐步抬高，VS2015（v140）能干净编过的窗口期并不宽，而 1.28 恰好落在一个相对稳定的区间里。它解决的不是“能不能用 gRPC”的问题，而是“在老工具链、老 Windows SDK、不能随便升级编译器的产线环境里，怎么把 gRPC 的 C++ 静态库和动态库编出来、并且能被自己的工程链接进去”。这篇内容面向的是需要在 Windows 上落地 gRPC C++ 的工程师，尤其是被 VS2015 锁死、又不想改整个构建体系的那批人。下面按“先立住原理和选型，再动手复现，最后讲坑”的顺序推。
2. 为什么是 1.28 加 VS2015：版本、工具链与依赖的三方博弈
2.1 gRPC C++ 在 Windows 上的构建底座
gRPC 的 C++ 实现并不是一个孤立的库，它在 Windows 上依赖一整套底层组件：Protocol Buffers、zlib、OpenSSL（或 BoringSSL）、c-ares、abseil（1.28 这个阶段还没完全切到 abseil 的强绑定，但部分模块已经引入）。这些依赖的版本和编译方式，直接决定了你能不能编过。gRPC 官方在 Windows 上主推的是 CMake 构建，配合 Visual Studio 生成器。VS2015 对应的是 CMake 里的Visual Studio 14 2015 Win64生成器，工具集是 v140。这里第一个容易翻车的点：很多人拿 VS2017/2019 的生成器去编，结果在 protobuf 的某些模板代码上直接报 C++ 标准不匹配。VS2015 默认只到 C++14 的部分特性，而 gRPC 1.28 的代码里已经用了不少 C++11/14 的写法，所以编译选项必须显式打开。
我一般会先确认三件事：CMake 版本不低于 3.13（1.28 的 CMakeLists 里用了target_link_libraries的新签名），NASM 已安装（OpenSSL 在 Windows 上编译汇编部分需要它），以及 Perl 可用（OpenSSL 的配置脚本依赖）。这三样缺一个，后面就会在某个依赖的 configure 阶段卡住，而且报错信息往往不指向根因。
2.2 选 1.28 而不是更高版本的实际理由
从工程角度看，选 1.28 通常不是因为它“新”，而是因为它“够用且可控”。更高的版本会引入更严格的编译器要求，比如对 MSVC 2017 以上工具集的硬依赖，或者对 C++17 的强制使用。VS2015 的 v140 工具集在这些要求面前基本没有还手之力。另一个现实因素是第三方依赖的版本漂移：gRPC 1.28 对应的 protobuf 是 3.7.x 到 3.8.x 区间，这个区间的 protobuf 在 VS2015 下的编译问题相对少，社区里能查到的补丁也集中。再往上，protobuf 自身就开始要求更高的 C++ 标准，连锁反应会把你拖进一个无底洞。
还有一点常被忽略：gRPC 1.28 的 CMake 脚本对 Windows 静态库的支持相对完整。如果你要做的是把 gRPC 编成静态库再嵌进自己的 DLL 或 EXE，这个版本的gRPC_MSVC_STATIC_RUNTIME和gRPC_BUILD_CSHARP_EXT之类的开关行为比较可预期。更高版本里这些开关的默认值和交互逻辑改过几轮，老工程迁移时容易踩到链接期的一堆符号缺失。
2.3 依赖清单与版本对应关系
下面这张表是我在多次编译后整理出来的、在 VS2015 下相对稳的组合。注意版本号不是随便写的，每个都对应到 gRPC 1.28 的third_party子模块或官方推荐区间。
| 组件 | 建议版本 | 作用 | VS2015 下的注意点 |
|---|---|---|---|
| CMake | 3.13 到 3.16 | 生成 VS 工程 | 高于 3.16 可能引入新策略，老工程不认 |
| NASM | 2.13 以上 | 编译 OpenSSL 汇编 | 必须加入 PATH，否则 OpenSSL 配置失败 |
| Perl | 5.26 以上 | OpenSSL 配置脚本 | Strawberry Perl 即可，注意路径无空格 |
| OpenSSL | 1.1.1 系列 | TLS 支持 | 用no-asm可绕过 NASM，但性能下降 |
| zlib | 1.2.11 | 压缩 | 直接用 gRPC 子模块里的版本最稳 |
| protobuf | 3.7.x 到 3.8.x | 序列化 | 不要混用系统里已装的 protoc |
| c-ares | 1.15 左右 | 异步 DNS | 1.28 子模块自带，一般不用单独编 |
这张表的核心逻辑是：能用的子模块就用 gRPC 自带的，不要自己去外面找一个“更新”的版本替换。替换带来的版本错配，在链接期会以各种未定义符号的形式爆发，排查成本极高。
3. 从零把 gRPC 1.28 编成 VS2015 可链接的库
3.1 源码获取与目录准备
第一步是把 gRPC 1.28 的源码和它的子模块一起拉下来。注意子模块必须递归拉取，否则third_party下面全是空目录，CMake 配置阶段就会报找不到 protobuf。
# 假设工作目录为 D:\grpc_build，路径不要有空格和中文 cd /d D:\grpc_build git clone --branch v1.28.0 https://github.com/grpc/grpc.git grpc cd grpc # 递归拉取子模块，这一步网络不稳会断，断了就重跑 git submodule update --init --recursive逻辑说明：--branch v1.28.0锁定标签，避免拉到主干上不兼容的提交。--recursive是必须的，gRPC 的third_party里嵌套了 protobuf、zlib、c-ares 等多个仓库。如果中途断掉，重新执行git submodule update --init --recursive即可，git 会续传。参数上唯一要注意的是路径：Windows 下路径带空格会让后续 CMake 和 Perl 脚本解析出错，所以工作目录尽量用纯英文无空格路径。
3.2 CMake 配置：生成 VS2015 工程的关键参数
配置阶段是整个流程里参数最密集的一步。下面这条命令是我在 VS2015 环境下反复用过的组合，生成的是 x64 的静态库工程。
cd /d D:\grpc_build\grpc mkdir .build cd .build cmake -G "Visual Studio 14 2015 Win64" ^ -DCMAKE_BUILD_TYPE=Release ^ -DgRPC_BUILD_TESTS=OFF ^ -DgRPC_BUILD_CSHARP_EXT=OFF ^ -DgRPC_INSTALL=ON ^ -DCMAKE_INSTALL_PREFIX=D:/grpc_build/install ^ -DgRPC_MSVC_STATIC_RUNTIME=ON ^ -DgRPC_SSL_PROVIDER=package ^ -DOPENSSL_ROOT_DIR=D:/grpc_build/openssl ^ -DOPENSSL_LIBRARIES=D:/grpc_build/openssl/lib ^ -DOPENSSL_INCLUDE_DIR=D:/grpc_build/openssl/include ^ ..逻辑说明：-G指定 VS2015 的 64 位生成器，这是和 v140 工具集绑定的。gRPC_BUILD_TESTS=OFF能砍掉大量测试目标的编译，省时间也省磁盘。gRPC_MSVC_STATIC_RUNTIME=ON表示用静态 CRT（/MT），如果你的主工程用 /MD，这里要改成 OFF，否则链接期会报 CRT 冲突。gRPC_SSL_PROVIDER=package表示用外部已编好的 OpenSSL，而不是让 gRPC 自己去编 BoringSSL，这样能避开 BoringSSL 在 VS2015 下的一些汇编兼容问题。
参数上最容易出错的是 OpenSSL 的三个路径。OPENSSL_ROOT_DIR指向你预先编好的 OpenSSL 安装目录，OPENSSL_LIBRARIES指向 lib 子目录，OPENSSL_INCLUDE_DIR指向 include。如果 OpenSSL 没编好，这一步 CMake 会直接报找不到ssl.h或crypto.lib。
3.3 编译与安装：用 MSBuild 而不是 IDE
配置成功后，.build目录下会生成grpc.sln。不要用 VS 打开去点“生成解决方案”，那样容易因为并行项目太多而内存爆掉。用 MSBuild 命令行，控制并行度。
# 找到 MSBuild，VS2015 默认在以下路径 set MSBUILD="C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" %MSBUILD% grpc.sln /p:Configuration=Release /p:Platform=x64 /m:4 /v:m # 编译完成后执行安装，把头文件和库拷到 install 目录 %MSBUILD% INSTALL.vcxproj /p:Configuration=Release /p:Platform=x64逻辑说明：/m:4表示最多 4 个并行项目，这个数字根据机器内存调整，16G 内存建议不超过 4，否则容易在链接阶段 OOM。/v:m是最小化日志输出，避免刷屏。安装目标INSTALL.vcxproj会把grpc.lib、grpc++.lib、protobuf.lib等以及对应的头文件拷到CMAKE_INSTALL_PREFIX指定的目录。
编译过程中如果卡在某个项目上超过十分钟，大概率是 protobuf 的代码生成阶段在跑，属正常。如果报错，优先看第一个报错的项目，后面的错误往往是连锁反应。
3.4 验证产物：写一个最小 C++ 工程链接测试
编完之后不要假设万事大吉，写一个最小工程验证链接和运行。下面是一个只创建 channel 的测试代码。
// test_grpc_link.cpp #include <grpcpp/grpcpp.h> #include <iostream> int main() { // 创建一个不连接的 channel，只验证库能否被链接和初始化 auto channel = grpc::CreateChannel("localhost:50051", grpc::InsecureChannelCredentials()); if (channel) { std::cout << "gRPC channel created, link OK" << std::endl; } return 0; }逻辑说明：这段代码不发起真实 RPC，只调用CreateChannel，目的是验证grpc++库能被正确链接，且运行时能找到依赖的 DLL（如果编的是动态库）。编译时在 VS2015 工程里需要把install/include加入附加包含目录，把install/lib加入附加库目录，并链接grpc++.lib、grpc.lib、libprotobuf.lib、zlib.lib、libssl.lib、libcrypto.lib等。如果链接报LNK2019，先检查是不是漏了ws2_32.lib和crypt32.lib，这两个是 Windows 网络和证书相关的系统库，gRPC 在 Windows 上必须链接。
4. 避坑与排查：VS2015 编 gRPC 1.28 最常见的五类翻车
4.1 报错 C2872 或 C2039：C++ 标准没打开
现象：编译 protobuf 或 gRPC 源码时，报某个类型“不明确”或某个成员“不是成员”，位置集中在模板和std::相关代码。
原因：VS2015 默认的 C++ 语言标准不启用 C++14 的某些特性，而 gRPC 1.28 的代码里用了变参模板、std::make_unique等。
解决：在 CMake 配置时追加-DCMAKE_CXX_FLAGS="/std:c++14"，或者在生成的 VS 工程里把所有项目的“C/C++ -> 语言 -> C++ 语言标准”改为“ISO C++14 标准”。注意 VS2015 对 C++14 的支持是部分的，如果遇到constexpr相关的报错，只能手动改源码或找社区补丁。
4.2 链接期 LNK2038：CRT 运行库不匹配
现象：链接自己的工程时，报LNK2038: 检测到“RuntimeLibrary”的不匹配项，值在MT_StaticRelease和MD_DynamicRelease之间冲突。
原因：gRPC 编译时用了静态 CRT（gRPC_MSVC_STATIC_RUNTIME=ON），而你的主工程用的是动态 CRT（/MD），或者反过来。
解决：统一两边。如果主工程是 /MD，重新配置 gRPC 时把gRPC_MSVC_STATIC_RUNTIME设为 OFF，重新编译。如果主工程是 /MT，保持 ON。不要试图用ignore指令绕过，运行期会出现堆跨模块释放的崩溃。
4.3 OpenSSL 配置失败：找不到 nasm 或 perl
现象：CMake 配置阶段报Could not find NASM或Perl not found，导致 OpenSSL 相关目标无法生成。
原因：OpenSSL 的 Windows 构建脚本依赖 NASM 编译汇编优化部分，依赖 Perl 解析配置。
解决：安装 NASM 和 Strawberry Perl，并把它们的可执行文件目录加入系统 PATH。如果实在不想装 NASM，可以在配置 OpenSSL 时加no-asm参数，但 TLS 性能会下降，产线环境不建议。另一个办法是直接用预编译的 OpenSSL 1.1.1 库，跳过自己编译这一步。
4.4 编译到一半内存耗尽或 MSBuild 崩溃
现象：MSBuild 在编译某个大项目（通常是grpc或grpc++）时进程消失，或者报out of memory。
原因：并行编译的项目太多，每个 MSVC 编译器实例都吃内存，16G 内存开 8 个并行很容易爆。
解决：把/m后面的数字降到 2 或 3，或者分步编译：先单独编libprotobuf，再编grpc，最后编grpc++。用%MSBUILD% grpc.sln /t:项目名可以只编指定项目。
4.5 运行期报缺少 DLL 或 0xc000007b
现象：编译出的 exe 在别的机器上跑，报找不到grpc++.dll或直接0xc000007b（架构不匹配）。
原因：编的是动态库，但运行时没把 DLL 放到 exe 同目录或系统 PATH；或者 exe 是 32 位而 DLL 是 64 位。
解决：用 Dependency Walker 或dumpbin /dependents检查依赖。产线环境建议直接编静态库（gRPC_MSVC_STATIC_RUNTIME=ON配合静态链接），把依赖降到最低。如果必须用动态库，把所有依赖 DLL 和 exe 放同一目录，不要依赖系统 PATH。
5. 进阶：把 gRPC 1.28 集成进现有 VS2015 工程的三个具体技巧
5.1 用属性表（.props）统一管理包含目录和库目录
在 VS2015 里手动给每个项目加包含目录和库目录是体力活，也容易漏。更稳的做法是建一个grpc.props属性表，把install/include、install/lib、以及需要链接的库名都写进去，然后在所有需要 gRPC 的项目里导入这个属性表。属性表里用$(GRPC_ROOT)这样的用户宏，方便换机器时只改一处。具体做法：在 VS 的“属性管理器”里右键项目 -> 添加现有属性表，或者直接编辑.props文件，把AdditionalIncludeDirectories和AdditionalDependencies写进去。这样新加项目时导入一次即可，不用重复配置。
5.2 处理 protoc 代码生成：把 .proto 编译集成到构建流程
gRPC 工程里.proto文件需要先用protoc生成.pb.cc和.grpc.pb.cc，再参与编译。手动生成容易忘，建议在 VS 工程里加自定义生成步骤。在.proto文件的属性里，把“自定义生成工具”的命令行设为：
D:\grpc_build\install\bin\protoc.exe --grpc_out=. --plugin=protoc-gen-grpc=D:\grpc_build\install\bin\grpc_cpp_plugin.exe -I=. %(Filename).proto D:\grpc_build\install\bin\protoc.exe --cpp_out=. -I=. %(Filename).proto输出文件设为%(Filename).pb.cc和%(Filename).grpc.pb.cc，并把它们加入工程编译。注意grpc_cpp_plugin.exe必须和protoc.exe版本匹配，混用不同版本的插件会生成不兼容的代码。
5.3 用静态库加 /WHOLEARCHIVE 解决符号被裁剪
如果 gRPC 编的是静态库，链接时 MSVC 默认只拉取被引用到的目标文件，而 gRPC 里有些注册机制（比如服务注册）依赖静态初始化，可能被裁掉导致运行期找不到服务。解决办法是在链接器选项里加/WHOLEARCHIVE:grpc++.lib和/WHOLEARCHIVE:grpc.lib，强制把整个库的目标文件都链进来。代价是 exe 体积变大，但能避免“编译链接都过、运行期服务找不到”这种玄学问题。这个技巧在产线环境里救过我好几次，尤其是服务端程序。
最后说一个我自己的习惯：每次编完 gRPC，我都会把install目录整个打包备份，连同 CMake 的配置命令一起写进一个build_notes.txt。因为 VS2015 加 gRPC 1.28 这套组合，隔半年再回来编，环境变量和依赖版本很容易记混，有备份和命令记录能省掉重新踩坑的时间。希望帮到你。
本文还有配套的精品资源，点击获取
