在未配置死信主题时，pub/sub 不允许设置最大投递次数；若强行配置但未启用死信主题，消息将无限重试直至被确认、死信主题就绪或超出消息保留期限。
Google Cloud Pub/Sub 的消息生命周期管理依赖于确认机制（acknowledgement）和订阅级配置协同工作。你提到的三项配置——10 分钟（600 秒）的确认截止时间、最大投递次数设为 10、且未启用死信主题——看似合理，实则存在一个关键前提被忽略：maxDeliveryAttempts 字段仅在同时配置了有效的死信主题（Dead Letter Topic）时才生效。
⚠️ 配置有效性校验
当你在创建或更新订阅时指定 maxDeliveryAttempts: 10 却未设置 deadLetterPolicy，Pub/Sub API 会拒绝该请求并返回错误（如 INVALID_ARGUMENT），除非你使用的是较旧的客户端库或通过非标准方式绕过校验（不推荐）。因此，在合规配置下，不存在“设置了 maxDeliveryAttempts 但无死信主题”的合法状态。
若因特殊原因（例如死信主题被意外删除、IAM 权限失效、网络隔离等）导致死信路径不可用，Pub/Sub 的实际行为如下：
- 消息在达到 maxDeliveryAttempts 次失败后，不会丢弃，也不会进入“静默归档”状态；
- 它将持续保留在订阅中，并在每次重试窗口（基于指数退避策略）到期后重新投递给订阅者；
- 此期间，该消息的 oldest_unacked_message_age_ms 指标将持续增长，直到满足以下任一条件：
- 订阅者最终成功 ACK；
- 死信主题恢复可用且权限正确，消息被自动转发；
- 消息超过订阅的 messageRetentionDuration（默认 7 天，最长 31 天），被系统自动清除。
✅ 正确实践建议
# 创建带死信主题的订阅（示例：gcloud CLI）
gcloud pubsub subscriptions create my-sub \
--topic=my-topic \
--ack-deadline=600 \
--max-delivery-attempts=10 \
--dead-letter-topic=projects/my-project/topics/dlq-topic \
--dead-letter-max-delivery-attempts=5? 注意：死信主题本身也需独立配置 maxDeliveryAttempts（用于其自身投递失败场景），形成可收敛的错误处理链。
? 监控关键指标
建议在 Cloud Monitoring 中重点关注：
- pubsub_subscription_oldest_unacked_message_age
- pubsub_subscription_nack_count
- pubsub_subscription_dead_letter_messages_published_count
这些指标能帮助你及时发现长期未确认消息、频繁 NACK 或死信投递异常等问题。
总结：Pub/Sub 的可靠性设计以“不丢失”为优先原则。没有死信主题，maxDeliveryAttempts 形同虚设；而一旦启用，它将成为消息生命周期终止的关键开关。务必确保死信主题存在、可写、且具备合理的监控告警机制，才能真正实现可控的错误消息治理。
