go模块（go mod）不参与调度，实际调度由应用并发控制、服务间流量路由和go运行时gmp模型三层独立实现；grpc拦截器中改写目标地址需用全限定域名；rate.limiter的allow()与wait()行为不同，须依场景选用；semaphore.weighted使用必须严格配对acquire与release。
Go模块本身不参与调度，别被名字误导
“Go模块调度”这个说法本身就容易引发误解——go mod 是包依赖管理机制，不是运行时调度器。它不控制 Goroutine 执行顺序、不干预 CPU 分配、也不影响请求分发。你看到的“调度”行为，实际来自三类独立系统：应用内并发控制（rate.Limiter / semaphore.Weighted）、服务间流量路由（gRPC 拦截器 + Istio）、以及 Go 运行时自身的 GMP 调度模型。混淆这三层，会导致你在调试超时、限流失效或跨集群转发失败时，错误地去改 go.mod 或重写 go build 参数。
gRPC 拦截器里做调度，host 必须用全限定域名
如果你在 gRPC 服务中通过拦截器读取 x-cluster-preference 并尝试改写目标地址，但发现流量始终没进指定集群，大概率是 DestinationRule.host 配置错了。Istio 不认简写名：
-
myapp❌ —— Istio 无法解析为跨集群服务 -
myapp.default.svc.cluster.local✅ —— 必须带 namespace 和svc.cluster.local后缀
Go 代码里调用 grpc.Dial 时，target 地址可以是任意字符串（比如 "passthrough:///"），但最终路由决策完全由 Istio 控制；拦截器只能透传 header 或附加 metadata，不能绕过控制平面。一旦 FQDN 不匹配，VirtualService 的 subset 分流会静默失效，日志里几乎不报错。
rate.Limiter.Wait() 和 Allow() 别混用
限流逻辑写在 HTTP handler 里，但 limiter.Allow() 和 limiter.Wait(ctx) 行为差异极大：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
Allow()是瞬时采样：返回 true/false，不阻塞，适合打点监控或降级开关判断 -
Wait(ctx)是阻塞等待：直到拿到令牌或 context 超时，适合 API 接口级限流 - 用
Wait(ctx)时必须传入带 deadline 的 context，否则可能永久挂起 -
rate.NewLimiter(100, 5)表示“每秒补 100 令牌，桶初始容量 5”，突发 5 个请求立刻通过，第 6 个开始排队——这不是硬实时节奏，要严格间隔需换漏桶实现（如ratelimit库）
集群级限流必须外接 Redis + Lua 原子计数；本地 rate.Limiter 只管单进程，Redis 不可用时得 fallback 到本地并记录告警，不能直接 panic 或跳过限流。
semaphore.Weighted.Acquire 必须配 defer Release
用 semaphore.Weighted 控制并发任务数（比如导出、渲染、批量写库），最容易踩的坑是忘记释放或释放数量不对：
-
sem.Acquire(ctx, 1)可能返回context.Canceled或context.DeadlineExceeded，忽略错误会导致 goroutine 永久挂起 - 必须写
defer sem.Release(1)，且 Release 的数值必须和 Acquire 完全一致 - Acquire 不能在 goroutine 外调用——否则所有任务串行执行，失去并发意义
- 如果配合缓冲 channel 使用（如
chan Task），channel 长度要大于 semaphore 的最大 acquire 数，否则写入阻塞会拖垮整个调度队列
信号量状态一旦破坏（多放/少放），后续 Acquire 行为不可预测，且无自动恢复机制。生产环境建议加 metrics 上报 acquire/release 偏差值。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
