Go RPC方法参数何时需使用指针？规则与原因解析

Great question—this is one of those Go RPC rules that makes sense once you dig into how the framework actually works under the hood. Let’s break it down clearly.

Why the second (reply) argument must be a pointer #

The Go RPC spec enforces this for a core reason tied to Go’s pass-by-value function semantics:

• Enable result round-trip: When you pass a non-pointer argument to a Go function, it’s copied. If the reply parameter were a value type (like int instead of *int), any changes the RPC server makes to it would only modify a local copy inside the method. Once the method returns, that copy is discarded, and the client would never see the computed result. Using a pointer lets the server directly modify the memory address that the client’s variable points to, so the result propagates back correctly.
• Framework serialization needs: The underlying RPC serialization/deserialization logic relies on pointers to write response data back to the client’s memory space. Without a pointer, there’s no way for the framework to transfer the server’s output to the client’s original variable.

For context, here’s the official method signature that highlights this rule:

func (t *T) MethodName(argType T1, replyType *T2) error

replyType *T2 is non-negotiable here—this is how RPC achieves the "call and get a result" pattern across network boundaries.

Why the first (argument) argument is often a pointer #

While the RPC spec doesn’t require the first argument to be a pointer, most real-world examples use one for these practical reasons:

• Cut down on copy overhead: If the argument is a large struct or complex type, passing it by value creates an expensive full copy of the data. Using a pointer avoids this extra memory cost, which is especially valuable in RPC scenarios where data is already being serialized and sent over the network.
• Distinguish "unset" from zero values: A pointer can be nil, which lets you explicitly signal that an argument wasn’t provided. Value types, by contrast, always have a zero value (like 0 for int or "" for string), which might overlap with valid input values. This is critical for APIs with optional parameters.
• Keep code consistent: Using pointers for both arguments makes method signatures uniform. It removes the mental burden of remembering which parameter needs a pointer and which doesn’t, making the code more readable and maintainable.

Take your example to see this in action:

func (t *Arith) Multiply(args *Args, reply *int) error {
    *reply = args.A * args.B
    return nil
}

Here, args *Args avoids copying the entire Args struct, and reply *int ensures the server can write the product back to the client’s variable.

内容的提问来源于stack exchange，提问作者dong