Go net/rpc 默认无认证，需在连接建立后、方法分发前插入认证鉴权：HTTP模式用Header传Token并封装Handler；TCP模式需自定义AuthConn实现握手认证；方法级鉴权推荐业务层自行校验权限并透传用户上下文。

Go net/rpc 默认不支持认证，必须自己加拦截层

Go 标准库的 net/rpc 本身是裸协议，没有内置身份校验、Token 验证或权限控制。所有请求只要能连上 TCP 或 HTTP 端口，就能调用注册的函数。这意味着：如果直接暴露 rpc.ServeConn 或 http.Serve，等同于把服务接口完全敞开。

真实生产环境必须在 RPC 调用链路中插入认证与鉴权逻辑。最可行的方式不是改标准库，而是在连接建立后、方法分发前做检查——也就是“连接级认证”或“方法级鉴权”。

使用 http.Request.Header 传递 Token 实现基础认证

当用 http.Serve 暴露 RPC（即 rpc.HandleHTTP()）时，底层走的是 HTTP 协议，可复用 http.Handler 中间件模式。此时客户端需在请求头里带凭证，服务端从 http.Request.Header 提取并验证。

• 客户端调用前需手动设置 Header：req.Header.Set("Authorization", "Bearer eyJhb...")
• 服务端需包装 http.DefaultServeMux，在转发前检查 req.Header.Get("Authorization")
• 注意：标准 rpc.Server 不解析 Header，必须自己写 wrapper；否则 Token 信息进不到业务逻辑
• 不建议用 URL 参数传 Token（易泄露、被日志记录、无加密）

func authHandler(h http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        token := r.Header.Get("Authorization")
        if !isValidToken(token) {
            http.Error(w, "Unauthorized", http.StatusUnauthorized)
            return
        }
        h.ServeHTTP(w, r)
    })
}

http.Handle("/rpc", authHandler(http.DefaultServeMux))

在 ServeConn 中对底层 net.Conn 做握手认证

若用 TCP 直连（如 rpc.ServeConn(conn)），没有 HTTP Header 可用，就得在连接建立后、RPC 消息流转前，约定一个轻量握手协议：客户端先发一段认证数据（如 JSON 或二进制 token），服务端验证通过才允许后续 RPC 流量。

• 不能在 rpc.ServeConn 后再读 conn —— 它会立即开始解析 RPC 编码，提前读会破坏消息边界
• 正确做法：自定义 net.Listener 的 Accept() 方法，在返回 conn 前完成认证
• 或者封装一个 AuthConn 类型，实现 net.Conn 接口，在 Read() 第一次调用时先处理握手
• 握手失败应直接关闭 conn，避免资源占用

type AuthConn struct {
    net.Conn
    authenticated bool
}

func (c *AuthConn) Read(p []byte) (n int, err error) {
    if !c.authenticated {
        // 读取并校验握手帧
        if !doHandshake(c.Conn) {
            return 0, errors.New("auth failed")
        }
        c.authenticated = true
    }
    return c.Conn.Read(p)
}

方法级鉴权需修改 Server.Register 或用反射注入检查逻辑

连接认证只解决“谁可以连”，不解决“能调什么”。要限制用户只能调用特定方法（比如普通用户不能调用 DeleteUser），得在方法执行前做权限判断。Go rpc.Server 不提供钩子，常见做法有：

• 不直接注册原始 handler，而是注册一层 wrapper 函数，内部检查 service/method + 当前用户角色
• 用 reflect 动态包装所有导出方法，在 Call() 前插入鉴权逻辑（需维护 method → permission 映射表）
• 更稳妥的是：把权限判断下沉到业务方法内部，由每个 handler 自己调用 checkPermission(ctx, "user:delete") —— 这样逻辑清晰、易于测试，也避免框架层过度耦合
• 注意：context.Context 无法自动从 RPC 请求中提取，需在认证阶段将用户信息存入 context，并透传给 handler（例如用自定义 ServerCodec 注入）

真正难的不是加一行 if !hasPerm(u, "xxx")，而是怎么让这个 u（用户身份）可靠地、端到端地流经整个调用链。很多团队卡在这一步，最后退回到只做连接认证，然后靠网络层（如防火墙、k8s NetworkPolicy）补位。