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 流量。
立即学习“go语言免费学习笔记（深入）”；
- 不能在
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）补位。
