微服务拆分时数据耦合的判断关键在于数据归属与变更节奏：若订单状态更新依赖用户认证字段（如is_blocked），则属强关联，应保留在同一限界上下文；共用order_items表但读写分离可接受，而创建订单需同步扣减库存且跨表加锁，则暴露强一致性依赖，不可硬拆。
服务拆分时数据耦合怎么判断
强行按功能切分但共享数据库，等于把单体包进多个进程——这是最常见也最危险的“伪微服务”。关键不是看模块名，而是看数据归属和变更节奏。
-
ID字段在订单表和用户表里都存在，不等于能拆；要看订单状态更新是否依赖用户认证表的字段（比如is_blocked），如果强关联，就得保留在同一限界上下文 - 两个模块共用一张
order_items表，但一个只读、一个只写，且写入逻辑不跨事务边界，可以接受；但如果订单创建要同步扣减库存，而库存记录在另一张表里且更新需加分布式锁，说明已隐含强一致性依赖，不能硬拆 - 用
go tool trace抓一次典型请求链路，看 SQL 查询是否跨多个服务边界执行——若GET /orders/123内部触发了对user-service的 HTTP 调用，再查users表，说明数据没真正隔离
gRPC 和 HTTP 通信选哪个
不是“哪个更好”，而是“在哪用、为什么用”。混用才是常态，但必须有明确分工。
- 内部服务间调用一律走
gRPC：协议更紧凑（Protobuf 序列化比 JSON 小 40%+），支持流式响应、双向流、内置超时与截止时间，grpc-go默认启用 HTTP/2 多路复用，连接复用率高 - 对外暴露统一走
HTTP（REST 或 GraphQL）：前端、第三方系统无法直接消费 Protobuf，且调试成本高；用grpc-gateway自动生成 REST 接口，避免手写两套路由逻辑 - 别在
gRPC里传大文件或二进制 blob——它默认限制 4MB 消息大小，改配置容易引发内存泄漏；上传下载类场景，用HTTP返回 presigned URL，让客户端直传对象存储
服务注册失败导致启动卡住怎么办
本地开发或 CI 环境里，consul 或 nacos 未就绪时，服务常卡在 app.Run() 不返回，根本原因不是网络不通，而是注册逻辑阻塞了主 goroutine。
- 注册超时必须显式设，比如
kratos.RegistrarTimeout(5 * time.Second)，否则默认无限等待 - 健康检查端点（如
/health）要在注册前就监听，否则 Consul 认为服务不可用，反复摘除又注册 - 开发阶段加 fallback：检测到注册中心不可达时，自动降级为本地服务发现（如读取
config.yaml中的静态 endpoints），避免整个链路瘫痪 - 别把注册逻辑塞进
init()——它无法被 context 控制取消，一旦失败只能 panic，应放在main()启动流程中，配合context.WithTimeout
日志和链路追踪为什么总对不上
不是工具没配好，而是 context 传递断点了。Go 的 context.Context 是唯一可靠载体，但手动传参极易遗漏。
- HTTP handler 里用
c.Request.Context()，别用context.Background()新建；gRPC server 里用ctx参数，别在 goroutine 里丢掉 - 中间件顺序很重要：
tracing.Server()必须在circuitbreaker.Server()之前，否则熔断触发时 trace ID 已丢失 - 异步任务（如发 MQ 消息后起 goroutine 处理）必须显式拷贝 context：
go func(ctx context.Context) { ... }(ctx)，否则子 goroutine 拿不到 span - 日志库必须支持
log.WithContext(ctx)，否则zap或logrus的WithFields无法注入 trace_id
实际落地最难的从来不是技术选型，而是每次服务调用前那句 ctx, cancel := context.WithTimeout(ctx, 3*time.Second)——漏写一次，整条链路就断成两截。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
