我正在努力提高 Go gRPC 服務(wù)器的覆蓋范圍，但在為服務(wù)器的攔截器功能編寫測試時遇到了麻煩，因為我無法有意義地滿足該UnaryHandler類型。Interceptor我有一個具有以下簽名的函數(shù)：Interceptor func(  ctx context.Context,  req interface{},  info *grpc.UnaryServerInfo,  handler grpc.UnaryHandler, // <- my issue comes from here) (interface{}, error)我假設(shè)任何 gRPC 方法都會滿足以下簽名UnaryHandler：type UnaryHandler func(ctx context.Context, req interface{}) (interface{}, error)所以我嘗試傳遞帶有此簽名的方法：GetToken(ctx context.Context, req *AuthData) (*Token, error)我想象這會起作用，因為這就是攔截器實際上正在做的事情（轉(zhuǎn)發(fā)該 RPC），但由于某種原因 Go 抱怨：無法在攔截器的參數(shù)中使用 authService.GetToken (type func(context.Context, *AuthData) (*Token, error)) 作為類型 grpc.UnaryHandler我繼續(xù)編寫了一個正確滿足以下條件的虛擬函數(shù)：func genericHandler(ctx context.Context, req interface{}) (interface{}, error) {    return req, nil}這很好，因為我在測試攔截器時并不特別需要運行任何特定方法。然而，我很好奇為什么實際方法不滿足約束，因為（根據(jù)我的理解）每當(dāng)我在野外調(diào)用該 RPC 時，它都會被傳遞到底層的攔截器函數(shù)。最可能的解釋是 grpc UnaryHandler 沒有做我想象的那樣，但是它做了什么？