需采用渐进式路径改造：第一步完成单体模块化分层；第二步用goctl生成并验证用户RPC服务；第三步让原API调用该RPC；第四步剥离数据库实现服务自治。
想用 Go-Zero 把一个单体 API 项目逐步改造成可独立部署、可弹性伸缩的微服务架构，又担心一步到位拆散后无法调试、联调失败、接口不通或数据错乱？你需要的不是从零写四个服务，而是清晰可执行的渐进式路径。
第一步：确认单体 API 已稳定运行并完成模块化分层
在动刀拆服务前，必须确保当前单体项目已按业务逻辑做了清晰的 package 划分，例如 user/、order/、product/ 目录各自封装了完整的数据访问与业务逻辑，且无跨目录强引用（如 order 包直接 import "main/db"）。若仍存在大量全局变量、共享数据库连接池混用、SQL 手写耦合在 handler 层，则必须先重构——【未完成模块化分层的单体，强行拆微服务只会放大混乱】。
运行 go list -f '{{.Name}}' ./... 确认所有子目录已作为独立包被识别；手动检查 main.go 中是否只剩路由注册和启动逻辑，无业务代码残留。
第二步：用 goctl 生成第一个 RPC 服务（以用户服务为例）
方法一：基于 proto 定义生成骨架
在项目根目录下执行：mkdir -p rpc/user && cd rpc/user → 创建 user.proto 文件，写入标准定义（含 go_package = "./user"）→ 运行 goctl rpc proto -src user.proto -dir . 生成 server、client、types 全套代码。
方法二：复用已有业务逻辑快速对接
将原单体中 user/ 目录下的 DAO 层（如 usermodel.go）和 biz 层（如 userlogic.go）整体复制到新生成的 rpc/user/internal/logic/ 下；修改 NewUserLogic 初始化时传入的 data 层实例，指向你迁移后的 repository 实现；【注意：不要直接复用单体中的 database/sql.DB 全局变量，必须通过依赖注入传入】。
方法三：本地验证 RPC 接口可用性
在 rpc/user 目录下执行 go run user.go -f etc/user.yaml 启动服务 → 新开终端用 goctl 生成的 client 示例调用 getUser → 确认返回结构正确且延迟在 10ms 内，再进入下一步。
第三步：改造原单体 API 为“调用方”，对接新 RPC 服务
第一步：在原 api 服务的 go.mod 中添加对 rpc/user 的本地依赖：replace go-zero-demo/rpc/user => ../rpc/user。
第二步：在 api/internal/handler/userinfohandler.go 中，删除原数据库查询逻辑，改为初始化 userclient 并调用 RPC 方法：res, err := l.svcCtx.UserRpc.GetUser(l.ctx, &user.IdRequest{Id: userId})。
第三步：启动顺序必须严格遵循 → 先启动 rpc/user → 再启动 api → 使用 curl 测试 /user/info 接口，观察日志中是否出现 “user rpc call success” 类似输出。
这一步操作起来很简单，但容易卡在服务发现环节：若未配置 etcd 或 nacos，go-zero 默认使用直连模式，需确保 api.yaml 中 RemoteAddr 指向的是 rpc/user 实际监听的地址（如 127.0.0.1:9000），而非 localhost 或 0.0.0.0。
第四步：剥离数据库所有权，实现真正的服务自治
① 在 rpc/user/etc/user.yaml 中配置专属数据库连接串，与原单体使用的 DSN 完全隔离；
② 删除原单体代码中所有对 user 表的直接 SQL 查询（包括 JOIN 订单表等跨域操作）；
③ 若订单服务后续也需要用户昵称，不得在 order 服务里重写 SELECT name FROM user WHERE id=?，而必须通过 user RPC 的 GetUser 接口获取——【这是微服务边界成立的铁律，破则退化为分布式单体】；
④ 运行 sqlc 或 gormgen 为 rpc/user 单独生成 DAO，确保其 model 层不暴露给其他服务；
⑤ 执行一次全链路压测：模拟 500 QPS 请求 /user/info → 观察 rpc/user 的 CPU、内存、DB 连接数是否稳定，无泄漏。
