rpc方法签名无法直接校验参数，需提前拦截；go标准net/rpc强制方法签名为func(args, reply) error，仅保证调用成功（序列化、网络、panic），不校验业务参数合法性。
RPC 方法签名里不能直接校验，必须提前拦截
Go 标准 net/rpc 的方法签名强制为 func(*Args, *Reply) error，它只管调用是否成功（序列化、网络、函数 panic），不处理业务级参数合法性。你写 if args.ID 看似可行，但问题在于：错误被吞进 <code>error 返回值，客户端拿到的是模糊字符串，无法区分是“参数错”还是“服务崩了”，也没法定位到具体字段。
- 所有参数校验必须在进入 RPC 方法前完成，否则就失去结构化、可调试、可翻译的基础
- HTTP 模式下（
rpc.ServeHTTP）可用中间件拦截*http.Request，解析并校验 Body 或 Query - TCP 模式下（
rpc.ServeConn）需包装net.Conn，在首次Read()时解析请求帧（如 JSON-RPC 2.0 的 params 字段），失败即断连 - 别试图在
Args结构体上加validatetag 后靠反射自动校验——RPC 不调用你的校验逻辑，除非你手动在每个方法开头写err := validate.Struct(args)
用 go-playground/validator 校验 Args 结构体的正确姿势
虽然 RPC 不自动触发校验，但你可以把校验逻辑收口到统一入口，比如封装一个 ParseAndValidateRPC 函数，在中间件或 wrapper 中调用它。这时 validator 才真正有用，但默认配置会踩坑：
- 必须调用
Validate.SetTagName("validate")，否则它会误读jsontag，导致omitempty和required冲突 -
time.Time字段不能直接接收字符串；应定义为string类型，再在Validate方法里手动解析：if _, err := time.Parse("2006-01-02", a.Date); err != nil { return err } - 嵌套结构体要显式加
dive，例如Profile *UserProfile `validate:"dive"`，否则只校验指针是否非 nil - 数组字段必须加
dive，如Tags []string `validate:"required,dive,min=1,max=5"`，否则只校验 slice 是否为空
错误返回必须走 Reply 字段，而非方法的 error
RPC 方法返回非 nil error 时，整个响应（包括 *Reply）都不会发给客户端——这是标准行为，不是 bug。所以业务错误（如“邮箱已注册”“余额不足”）绝不能靠返回 error 传递。
- 在
Reply结构体中嵌入错误字段，推荐用指针类型：Error *AppError `json:"error,omitempty"`，避免空值干扰 JSON 序列化 -
AppError必须是可序列化的结构体，含Code、Message、Field（可选），不能是errors.New包装的字符串 - 客户端收到响应后，先检查
reply.Error != nil，再按reply.Error.Code分类处理，而不是看call.Error（那是连接/解码错误） - HTTP 模式下若想复用 Web 层的统一错误格式（如
ErrorResponse），可把整个 RPC 响应包进{ "data": {}, "error": {} }结构，但需服务端和客户端约定好外层封装
Query、Header、Path 参数校验容易被忽略
RPC 通常只关注 Body（Args），但真实接口常混用多种参数来源：HTTP 请求的 query（如 /user?id=123）、header（如认证 Token）、path（如 /user/{id}）。这些都不经过 Args 解析，极易漏校验。
立即学习“go语言免费学习笔记（深入）”；
-
r.URL.Query().Get("page")返回string，必须手动转int并检查err != nil，失败立即返回 400，别传给后续逻辑 - Token 在
r.Header.Get("Authorization")，校验失败应返回 401，且不能继续执行 RPC 方法——这是认证，不是参数校验 - 路径参数（如 chi.Router）用
chi.URLParam(r, "id")取值，空字符串或非法格式（如非数字）必须拦截，否则传给Args.ID会导致后续解析 panic - 所有外部输入都要视为不可信，哪怕只是分页参数
limit，也得加lte=100限制，防 DoS
