gRPC在 C# 中不是“装完包就能跑”的框架，它依赖严格的契约驱动流程——
.proto文件必须先写对、再生成、再实现，三者错一步，编译或运行时就会报错。下面直奔实操要点。
怎么让 greet.proto
正确生成 C# 类？
生成失败是新手第一道坎，常见现象：
GreeterBase找不到、
HelloRequest类型不存在、编译提示 “The type or namespace name 'Grpc' could not be found”。根本原因通常是
.proto文件没被正确纳入构建流程。 确保项目文件（
.csproj）中包含
<protobuf></protobuf>项，且路径准确：
<ItemGroup> <Protobuf Include="Protos\greet.proto" GrpcServices="Server" /> </ItemGroup>
Grpc.Tools必须安装（服务端和客户端都要），它不参与发布，只在构建时调用
protoc；
Grpc.AspNetCore（服务端）和
Grpc.Net.Client（客户端）才是运行时依赖
option csharp_namespace必须与项目实际命名空间一致，否则生成的类会落在错误命名空间下，引用时找不到
为什么 SayHello
方法总返回 UNIMPLEMENTED
？
因为
GreeterBase是抽象基类，自动生成的默认实现直接抛出
RpcException。你必须提供具体子类并重写方法，否则任何客户端调用都会收到状态码
StatusCode.Unimplemented。 实现类必须继承
GreeterBase，且用
override显式重写方法 返回值必须是
Task<helloreply></helloreply>，不能用
async/await却忘了
return，也不能返回
null注册服务时，必须在
Program.cs中调用：
app.MapGrpcService<GreeterService>();
客户端连不上服务器？检查这三点
典型错误：客户端抛出
Status(StatusCode=Unavailable, Detail="failed to connect to all addresses")。这不是代码逻辑问题，而是通信链路未打通。 确认服务器监听的是
http://localhost:5001（或你配置的地址），且没有被防火墙/杀软拦截 客户端创建
Channel时，地址协议必须是
http://（开发阶段）或
https://（生产启用 TLS 后），不能漏掉协议头 若用 .NET 8+ + Kestrel 默认 HTTPS 模式，而客户端仍连
http://，会因 HTTP/2 不兼容直接拒绝连接——要么改客户端为
https://并信任证书，要么在服务器禁用 HTTPS 重定向（仅限开发）
命名管道（IPC）能用 gRPC
吗？
可以，但仅限 Windows，且必须显式配置 Kestrel 使用命名管道终结点。这是绕过网络栈、提升本地进程间通信性能的有效方式，但容易被忽略。
服务器端需在Program.cs中配置：
builder.WebHost.ConfigureKestrel(serverOptions =>
{
serverOptions.ListenNamedPipe("MyPipeName", listenOptions =>
{
listenOptions.Protocols = HttpProtocols.Http2;
});
});
客户端连接时使用 NamedPipeChannel（来自
Grpc.Net.Client），地址格式为
namedpipe://MyPipeName注意：命名管道不支持 TLS，也无需证书，但需考虑
PipeSecurity权限控制，否则非管理员进程可能无法连接
.proto文件是唯一真相源，所有生成、调用、调试都从它开始。别跳过验证——哪怕只是多加一个空格，也可能导致字段编号错位、序列化失败、客户端收不到字段值。先跑通一个最简
SayHello，再扩流式、再加认证、再上 TLS，节奏比堆功能更重要。
