Google Pub/Sub本身不提供本地缓冲能力，所有容灾和缓冲逻辑必须由服务自行实现；其ReceiveSettings直接影响多活架构下的吞吐与容错能力，需合理配置MaxOutstandingMessages、MaxOutstandingBytes及Synchronous参数，并确保subscription显式指定multi-regional location以支持跨区域高可用。
Google Pub/Sub 不是“缓冲地带”，而是强一致性、跨区域高可用的事件中继层；它本身不提供本地缓冲能力，所有容灾和缓冲逻辑必须由你的 Go 服务自己实现。
Pub/Sub 的 ReceiveSettings 直接决定消费端是否扛得住多活切换
默认配置下，ReceiveSettings.MaxOutstandingMessages 是 1，意味着每次只取 1 条消息，处理完才拉下一条——这在多活场景下会严重拖慢吞吐，也放大单点故障影响。多活架构要求每个 region 的消费者能并行处理、独立背压、故障时自动降级。
- 设为 0 表示无上限（危险，可能 OOM），生产环境建议按实例内存和 handler 耗时估算：比如单条处理平均 200ms，实例有 2GB 内存，可设为
500 -
ReceiveSettings.MaxOutstandingBytes必须同步调低（如10 * 1024 * 1024），防止大消息堆积撑爆内存 - 务必启用
ReceiveSettings.Synchronous=false，否则 ACK 延迟会卡死整个流控 - 多活 region 共用一个 subscription 时，需确认
EnableMessageOrdering关闭——它强制单分区顺序，会成为跨 region 扩展瓶颈
别指望 client.Publish 返回成功就等于事件已落盘
Go SDK 的 Publish 方法返回的是 *pubsub.PublishResult，它只是把消息塞进客户端内存队列，不是发到 Google 后端。你看到 result.Get(ctx) 成功，只代表消息被接收进 client buffer，不代表已写入 Pub/Sub 集群。
- 必须显式调用
result.Get(ctx)并检查 error；忽略它会导致“假成功”，消息静默丢失 - 如果要保障多活间事件不丢，发布侧得加本地 outbox：DB 提交后，再异步调
Publish，失败则轮询重试 + 记录失败事件 ID 到 DB - 不要在 HTTP handler 里直接
Publish后就返回 200；应先落库，再触发 goroutine 发布，避免请求中断导致事件丢失 - 测试时用
emulator模拟网络分区：kill emulator 进程后观察PublishResult是否真报错，而不是一直 hang
多活 region 共享 topic 时，subscription 的 location 配置是容灾关键
Pub/Sub 的 subscription 可以绑定到 multi-regional location（如 us 或 eur），但 Go SDK 创建 subscription 时不会自动继承——你得手动指定 Location 字段，否则默认创建在单 region，挂了就全断。
立即学习“go语言免费学习笔记（深入）”；
- 创建 subscription 时，用
pubsub.SubscriptionConfig{Location: "us"}，而不是留空或填us-central1 - 验证方式：查 GCP Console → Pub/Sub → Subscriptions → Details → “Location” 字段是否显示
Multi-regional (us) - 注意：multi-regional subscription 不支持
EnableMessageOrdering，这点和上一条冲突，需要业务权衡——要顺序还是要容灾 - 如果你用了
dead_letter_policy，DLQ topic 也必须建在同个 multi-regional location，否则跨 region 写入失败
真正难的不是连上 Pub/Sub，而是当一个 region 整体失联时，你的 Go 服务能否在不改代码、不人工介入的前提下，把未 ACK 的消息自动迁移到另一个 region 继续处理——这需要你在 consumer 里实现基于 Redis 或 etcd 的分布式 checkpoint 管理，Pub/Sub 本身不提供这个能力。
