Zero-Admin是基于go-zero的电商后台脚手架，含api（BFF层）、rpc（业务逻辑）、model（数据访问）三层结构：api层仅处理HTTP适配与轻量编排；rpc层承载核心业务与跨服务调用；model层专注单表CRUD，严格分层保障可维护性。
理解Go-Zero项目目录结构是开展微服务开发的第一步，否则容易把RPC逻辑写进API handler、在model里做HTTP响应封装，导致分层混乱、后续难以维护和测试。
api层：BFF网关与HTTP协议适配器
API层本质是面向前端或外部调用方的统一入口，只处理HTTP语义相关事务。
它不直接操作数据库，也不实现核心业务规则，而是将HTTP请求解析后，转交给RPC层执行，并把RPC返回结果格式化为JSON响应。
典型文件包括：hello.api（DSL定义接口）、hello.go（main入口）、etc/hello-api.yaml（端口/超时等配置）、internal/handler/xxxhandler.go（路由绑定+参数校验）、internal/logic/xxxlogic.go（仅做轻量编排，如调用多个RPC或加缓存）。
注意：handler中禁止出现SQL语句、Redis直连、复杂状态判断——这些都该下沉到RPC层。
rpc层：核心业务能力提供者
RPC层是纯内部服务，不暴露HTTP端口，只通过gRPC协议被其他服务调用。
它承载真实业务逻辑，比如“创建用户需校验手机号唯一性+生成邀请码+发注册短信”，这类跨资源、带事务边界的动作必须放在这里。
方法一：从proto定义出发生成骨架
编写user.proto → 执行goctl rpc protoc user.proto --go_out=./pb --go-grpc_out=./pb --zrpc_out=. → 自动生成pb/、rpc/、etc/、internal/等目录。
方法二：手动补全关键实现
在internal/logic/下编写具体逻辑，例如CreateUserLogic调用usermodel.Insert和smsclient.Send；internal/svc/servicecontext.go中注入所有依赖（MySQL连接、RPC客户端、Redis等）。
【proto中service名必须与生成的RPC客户端结构体名严格一致，否则zrpc.MustNewClient会panic】
model层：数据访问契约与CRUD封装
Model层是RPC层的下层依赖，只负责单表（或单集合）的增删改查，不包含任何业务判断。
第一步：确认数据库已建好对应表，且字段类型与proto message字段对齐（如proto中int64 id = 1对应MySQL的BIGINT）。
第二步：使用goctl model命令生成代码goctl model mysql ddl -src user.sql -dir ./model -c → 生成usermodel.go及配套types.go。
若无SQL文件，可用goctl model mysql datasource -url "root:pass@tcp(127.0.0.1:3306)/test" -table user -dir ./model -c直连抽取。
第三步：在RPC的logic中调用model方法
例如user, err := l.svcCtx.UserModel.FindOne(ctx, req.Id)，其中l.svcCtx.UserModel来自servicecontext.go中初始化的实例。
model层不处理事务边界，也不组合多表查询——复杂查询应由RPC logic层显式调用多个model或使用原生SQL（放在logic里，而非model里）。
