Redis Stream 的 XREADGROUP 配置了批量读取，并不代表业务处理会并发执行。一次实际排查中，Worker 的读取数量是 10，但消息处理函数仍在一个循环里同步调用，因此生成任务表现为“只能一个接一个执行”。修复后，单个 Worker 默认可以同时处理 4 个任务，并且并发上限可以通过环境变量调整。

对象存储的临时故障不应该让整个 API 进程无法启动。本文记录一次 Go 服务启动时检查 S3 Bucket 收到 400 Bad Request、容器随后退出的真实排查过程，并给出一套适用于 S3 兼容存储的启动策略。

任务状态显示 PROVIDER_SUBMISSION_UNKNOWN 时，不一定意味着模型服务没有返回结果。一次实际故障证明，供应商已经完成生图，失败发生在结果写入 R2 的最后一步。本文记录如何通过 Attempt 持久化数据还原真实数据流，并修正错误分类和凭据校验。

**解决一个编程问题之后，最容易被忽略的工作，是把“我当时怎么试出来的”整理成下一次可以复用的知识。**如果文章只有最终代码，读者看不到排查路径；如果文章只有流水账，又很难快速定位根因。
本文以一个 Hexo 博客的实际维护场景为例，整理一套从问题记录到 Git 发布的工作流：先保留事实，再抽取根因，最后用构建和版本控制保证文章真的能发布。