安全提取tenant_id需统一客户端用"tenant-id"，服务端用md.Get("tenant-id")并校验非空与格式；透传用自定义context key避免污染签名；PerRPCCredentials元数据丢失因HTTP目标被过滤，应改用TLS或dns:///前缀；数据库层须全局注入tenant_id条件、缓存键加租户前缀、RLS兜底。
gRPC拦截器里怎么安全提取tenant_id元数据
直接从metadata.MD里取tenant_id很容易panic或返回空值——因为gRPC元数据是map[string][]string，且大小写不敏感，但Go标准库的Get方法会自动转小写，而客户端可能发Tenant-ID或tenant-id，甚至混用横线和下划线。
实操建议：
- 统一约定客户端必须用
tenant-id（全小写+短横线），服务端只认这个key，避免歧义 - 用
md.Get("tenant-id")而不是md["tenant-id"]，前者做了nil-safe处理，后者可能panic - 取到的是
[]string，取第一个非空元素：if len(vals) > 0 && vals[0] != ""，不能直接vals[0] - 在拦截器开头就校验是否存在、是否合法（比如匹配
^[a-z0-9]{4,32}$），非法值直接返回status.Error(codes.Unauthenticated, "invalid tenant-id")
如何把tenant_id透传到业务Handler里不污染签名
gRPC Handler函数签名是固定的：func(ctx context.Context, req *XXXRequest) (*XXXResponse, error)，不能硬塞tenant_id进去。常见错误是把租户信息存在context.WithValue里，然后每个Handler自己去取——这看似干净，实则埋雷：一旦中间件顺序错、context被重置、或忘记传，就会静默降级成默认租户。
实操建议：
- 定义一个封装过的context key：
type tenantKey struct{}，避免用string做key导致冲突 - 在认证拦截器里调用
ctx = context.WithValue(ctx, tenantKey{}, tenantID)，仅此一处注入 - 业务Handler内统一用
tenantID, ok := ctx.Value(tenantKey{}).(string)判断，!ok视为严重错误，立刻返回codes.Internal - 不要在Repository层再做
ctx.Value提取——把它当成“已验证的输入”，直接作为参数传给DB查询函数，比如userRepo.ListByTenant(ctx, tenantID, filter)
WithPerRPCCredentials发元数据时为什么tenant_id总丢
客户端用credentials.PerRPCCredentials实现GetRequestMetadata，但每次调用都看不到tenant_id，日志里显示元数据为空。根本原因是：gRPC默认只对https目标发送自定义元数据，本地调试用localhost:8080或127.0.0.1:8080这类http地址时，元数据被静默过滤掉了。
实操建议：
- 开发期强制走TLS：用
localhost:8081配自签名证书，或改用dns:///localhost:8080（触发DNS解析绕过http限制） -
GetRequestMetadata里别依赖闭包变量，比如func() map[string]string { return map[string]string{"tenant-id": tenantID} }——tenantID得是调用时实时获取的，不是初始化时捕获的 - 加一行日志：
log.Printf("sending metadata: %+v", md)，确认是否真进了这个函数；如果没打日志，说明凭证根本没被调用，检查grpc.WithPerRPCCredentials是否漏传进grpc.Dial
多租户隔离在数据库层容易漏掉哪些关键点
光靠SQL里拼WHERE tenant_id = ?远远不够。最常踩的坑是：迁移脚本、后台任务、缓存预热、全文检索索引，全都默认查全量数据，一跑就跨租户泄露。
实操建议：
- 所有SQL模板强制包含
tenant_id占位符，哪怕当前逻辑说“这个表全局唯一”，也加AND tenant_id = @tenant_id并设默认值为当前上下文租户 - ORM如GORM，注册全局
BeforeFind回调，自动注入tenant_id条件，但注意：显式传了Unscoped()的查询会绕过它，这种地方必须人工review - Redis缓存键必须带
tenant_id前缀，比如cache:user:123改成cache:tenant-a:user:123，否则A租户删缓存会清掉B租户的 - PostgreSQL行级安全策略（RLS）可以兜底，但别当主力——它不生效于
psql直连、某些扩展函数、或管理员角色，得配合应用层双重校验
真正难的不是加一行WHERE，而是让每个新写的定时任务、每个临时导出脚本、每个DBA手动执行的UPDATE，都记得带上租户上下文。这没法靠技术全自动，得靠CR checklist和权限收敛。
