核心用法
本 Skill 提供了一套完整的 PostgreSQL 原生作业队列实现方案，核心依托 SKIP LOCKED 特性实现无竞争条件的作业认领机制。主要技术组件包括：
1. Schema 设计：采用 JSONB 存储任务数据，内置优先级调度（priority）、进度追踪（progress/current_stage）、 worker 绑定（worker_id/claimed_at）及重试机制（attempts/max_attempts/last_error）
2. 批处理认领：通过 claim_job_batch() 函数实现批量作业获取，利用 FOR UPDATE SKIP LOCKED 避免多 worker 死锁，配合部分索引（partial index）确保高并发下的查询性能
3. Go 参考实现：包含 PriorityExplicit/PriorityDiscovered/PriorityBackfill 三级优先级常量，以及 Claim/Complete/Fail/RecoverStaleJobs 完整生命周期管理
4. 过期恢复：RecoverStaleJobs 机制自动将超时未完成的作业重置为 pending 状态，防止任务丢失
显著优点
- 零外部依赖：直接复用现有 PostgreSQL 基础设施，避免引入 Redis/RabbitMQ 的运维成本
- ACID 保证：利用数据库事务确保作业状态变更的原子性，任务不会丢失
- 生产级特性：内置优先级队列、进度追踪、自动重试、死作业恢复等完整功能
- 高性能批处理：批量认领减少网络往返，SKIP LOCKED 实现无锁并发
- 透明可观测：标准 SQL 查询即可监控队列深度、处理延迟、失败率等指标
潜在局限
- 吞吐量上限：官方建议 <1000 jobs/sec 场景使用，高频场景需叠加 Redis 层
- 延迟敏感场景不适用：无法达到 Redis 的亚毫秒级延迟
- 顺序约束：严格 FIFO 需单 worker 处理，限制并行度
- 大负载处理：建议存储引用而非实际 payload，避免表膨胀
- 数据库耦合：队列性能受 PostgreSQL 实例规格和锁竞争影响
适合人群
- 已运行 PostgreSQL 但不想引入消息队列的团队
- 作业量中等（<1K/s）、重视数据一致性的业务场景
- 需要内置进度追踪和可视化能力的后台任务系统
- 希望减少技术栈复杂度的初创团队或中小规模项目
使用风险
- 性能风险：缺少部分索引时
claim_job_batch性能急剧下降，必须按文档创建idx_jobs_claimable - 并发风险：未使用 SKIP LOCKED 会导致 worker 死锁，必须使用文档推荐的 CTE + FOR UPDATE SKIP LOCKED 模式
- 数据清理风险：长期运行的队列需配合归档策略，防止 jobs 表无限增长
- 连接池耗尽：高并发 worker 场景需合理配置 pgx 连接池大小
- 超时配置：
RecoverStaleJobs的超时阈值需根据业务 SLA 谨慎设置，避免误杀正常长任务