⚡

软件后端工程 software-backend

软件后端工程技能用于设计、实现和审查生产级的后端服务，涵盖API设计、数据库管理、身份验证、缓存、可观测性、错误处理、测试和部署。关键词：后端开发、API设计、数据库、身份验证、缓存、可观测性、测试、部署、生产就绪、零信任架构、性能优化、成本控制。

后端开发 0 次安装 0 次浏览 更新于 3/7/2026

名称: software-backend 描述: 跨Node.js (Express/Fastify/NestJS/Hono)、Bun、Python (FastAPI)、Go和Rust (Axum)的生产级后端服务开发，使用PostgreSQL和常见ORM (Prisma/Drizzle/SQLAlchemy/GORM/SeaORM)。用于REST/GraphQL/tRPC API、身份验证 (OIDC/OAuth)、缓存、后台任务、可观测性 (OpenTelemetry)、测试、部署就绪和零信任默认。

软件后端工程

使用此技能设计、实现和审查生产级后端服务：API边界、数据层、身份验证、缓存、可观测性、错误处理、测试和部署。

默认偏向：类型安全边界（边缘验证）、OpenTelemetry用于可观测性、零信任假设、重试幂等性、RFC 9457错误、Postgres + 连接池、结构化日志、超时和速率限制。

快速参考

任务 默认选择 备注
REST API Fastify / Express / NestJS 偏好类型化边界 + 显式超时
Edge API Hono / 平台原生处理器 保持工作无状态，CPU轻量
类型安全 API tRPC 偏好用于TS monorepos和内部API
GraphQL API Apollo Server / Pothos 偏好用于复杂客户端驱动查询
数据库 PostgreSQL 使用连接池 + 迁移 + 查询预算
ORM / 查询层 Prisma / Drizzle / SQLAlchemy / GORM / SeaORM 偏好显式事务
身份验证 OIDC/OAuth + 会话/JWT 偏好浏览器使用httpOnly cookies
验证 Zod / Pydantic / 验证库 在边界验证，不在深层内部
缓存 Redis (或托管) 使用TTLs + 失效策略
后台任务 BullMQ / 平台队列 使任务幂等 + 重试安全
测试 单元 + 集成 + 契约/E2E 保持大多数测试在UI层以下
可观测性 结构化日志 + OpenTelemetry 端到端关联ID

范围

使用此技能来：

  • 设计和实现REST/GraphQL/tRPC API
  • 建模数据模式并运行安全迁移
  • 实现身份验证/授权 (OIDC/OAuth, 会话/JWT)
  • 添加验证、错误处理、速率限制、缓存和后台任务
  • 交付生产就绪（超时、可观测性、部署/运行手册）

何时不使用此技能

使用不同技能当：

决策树：后端技术选择

后端项目需求: [API类型]
  - REST API?
    - 简单CRUD -> Express/Fastify + Prisma/Drizzle
    - 企业功能 -> NestJS (DI, 模块)
    - 高性能 -> Fastify (紧凑请求生命周期)
    - Edge/Serverless -> Hono (Cloudflare Workers, Vercel Edge)

  - 类型安全API?
    - 全栈TypeScript monorepo -> tRPC (无模式，无代码生成)
    - 公共API带文档 -> REST + OpenAPI
    - 灵活数据获取 -> GraphQL + Pothos/Apollo

  - GraphQL API?
    - 代码优先 -> Pothos GraphQL (TypeScript)
    - 模式优先 -> Apollo Server + GraphQL Codegen

  - 运行时选择?
    - 企业稳定 -> Node.js (当前LTS)
    - 性能关键 -> Bun (验证运行时约束)
    - 安全优先 -> Deno (验证平台支持)

  - 身份验证策略?
    - 浏览器会话 -> httpOnly cookies + 服务器端会话存储
    - OAuth/社交 -> OIDC/OAuth库 (或平台身份验证)
    - 服务到服务 -> 短期JWT + 可能的mTLS

  - 数据库层?
    - 类型安全ORM -> Prisma (迁移, Studio)
    - SQL优先/性能 -> Drizzle (SQL类API)
    - 原始SQL -> 驱动 + 查询构建器 (Kysely/sqlc/SQLx)
    - Edge兼容 -> 驱动/ORM + Neon/Turso/D1

  - 缓存策略?
    - 分布式缓存 -> Redis (多服务器)
    - Serverless缓存 -> 托管Redis (例如, Upstash)
    - 内存缓存 -> 进程内存 (仅单实例)

  - Edge部署?
    - 全局低延迟 -> Cloudflare Workers
    - Next.js集成 -> Vercel Edge Functions
    - AWS生态系统 -> Lambda@Edge

  - 后台任务?
    - 复杂工作流 -> BullMQ (Redis支持, 重试)
    - Serverless工作流 -> AWS Step Functions
    - 简单调度 -> cron + 持久存储

运行时和语言替代方案：

  • Node.js (当前LTS) (Express/Fastify/NestJS + Prisma/Drizzle)：默认用于广泛生态系统 + 成熟工具
  • Bun (Hono/Elysia + Drizzle)：考虑用于性能敏感工作负载（验证运行时约束）
  • Python (FastAPI + SQLAlchemy)：强大用于数据密集型服务和ML集成
  • Go (Fiber/Gin + GORM/sqlc)：强大用于并发和简单部署
  • Rust (Axum + SeaORM/SQLx)：强大用于安全/性能关键服务

参见 assets/ 获取语言特定起始模板和 references/edge-deployment-guide.md 获取边缘计算模式。

API设计模式 (2025年12月)

幂等性模式

所有变异操作必须支持幂等性以确保重试安全。

实现：

// 幂等性密钥头
const idempotencyKey = request.headers['idempotency-key'];
const cached = await redis.get(`idem:${idempotencyKey}`);
if (cached) return JSON.parse(cached);

const result = await processOperation();
await redis.set(`idem:${idempotencyKey}`, JSON.stringify(result), 'EX', 86400);
return result;
做 避免
存储幂等性密钥带TTL (典型24h) 处理重复请求
为重复密钥返回缓存响应 相同密钥的不同响应
使用客户端生成UUID 服务器生成密钥

分页模式

模式 使用时机 示例
基于游标 大数据集，实时数据 ?cursor=abc123&limit=20
基于偏移 小数据集，随机访问 ?page=3&per_page=20
键集 排序数据，高性能 ?after_id=1000&limit=20

偏好基于游标的分页 用于频繁插入的API。

错误响应标准 (问题详情)

使用一致的机器可读错误格式 (RFC 9457 问题详情)：https://www.rfc-editor.org/rfc/rfc9457

{
  "type": "https://example.com/problems/invalid-request",
  "title": "Invalid request",
  "status": 400,
  "detail": "email is required",
  "instance": "/v1/users"
}

健康检查模式

// 存活检查：进程是否运行？
app.get('/health/live', (req, res) => {
  res.status(200).json({ status: 'ok' });
});

// 就绪检查：服务能否处理流量？
app.get('/health/ready', async (req, res) => {
  const dbOk = await checkDatabase();
  const cacheOk = await checkRedis();
  if (dbOk && cacheOk) {
    res.status(200).json({ status: 'ready', db: 'ok', cache: 'ok' });
  } else {
    res.status(503).json({ status: 'not ready', db: dbOk, cache: cacheOk });
  }
});

迁移回滚策略

策略 描述 使用时机
向后兼容 新代码适用于旧模式 零停机部署
扩展-收缩 添加新，迁移，移除旧 模式变更
影子表 在过渡期间写入两者 高风险迁移

常见后端错误避免

失败避免 正确做法 原因
在内存中存储会话 使用Redis/Upstash 重启时内存丢失，无水平扩展
同步文件I/O 使用 fs.promises 或流 阻塞事件循环，杀死吞吐量
无边界查询 始终使用 LIMIT + 游标分页 内存耗尽，响应慢
信任客户端输入 使用Zod在API边界验证 注入攻击，类型强制错误
硬编码密钥 使用环境变量 + 密钥管理器 (Vault, AWS SM) 仓库暴露时安全漏洞
N+1数据库查询 使用 include/select 或 DataLoader 10-100倍性能下降
生产中使用 console.log 使用结构化日志 (Pino/Winston) 无关联ID，不可查询日志
静默捕获错误 日志 + 重新抛出或显式处理 隐藏失败，调试噩梦
缺少连接池 使用Prisma连接池或PgBouncer 负载下连接耗尽
无请求超时 在HTTP客户端和DB查询上设置超时 资源泄漏，级联失败

安全反模式：

  • 失败 不要使用MD5/SHA1作为密码 -> 使用Argon2id
  • 失败 不要将JWT存储在localStorage -> 使用httpOnly cookies
  • 失败 不要信任 X-Forwarded-For 而不验证 -> 配置可信代理
  • 失败 不要跳过速率限制 -> 使用滑动窗口 (Redis) 或令牌桶
  • 失败 不要记录敏感数据 -> 删除PII、令牌、密码

可选：AI/自动化扩展

注意：AI辅助后端模式。如果不使用AI工具则跳过。

AI辅助代码生成

工具 使用案例
GitHub Copilot 内联建议，样板代码
Cursor AI优先IDE，上下文感知
Claude Code CLI基础开发

审查AI生成代码的要求：

  • 所有导入针对package.json验证
  • 类型检查器通过（严格模式）
  • 安全扫描通过
  • 测试覆盖生成代码

基础设施经济学和业务影响

为何重要：后端决策直接影响收入。100ms延迟增加可减少转化率7%。不良架构选择可能导致云支出10倍成本。性能SLA是收入承诺。

成本建模快速参考

决策 成本影响 收入影响
Edge vs. Origin 60-80% 延迟减少 +2-5% 转化率
Serverless vs. 容器 可变成本，缩放到零 低规模下更好的单位经济学
预留 vs. 按需 30-60% 成本节省 可预测COGS
连接池 50-70% 更少DB连接 降低数据库成本
缓存层 80-95% 更少源请求 减少计算成本

性能SLA -> 收入映射

SLA目标 -> 业务指标

P50延迟 < 100ms -> 基础用户体验
P95延迟 < 500ms -> 95%用户满意
P99延迟 < 1000ms -> 企业SLA合规
正常运行时间 99.9% (43.8m 停机/月) -> 标准SLA层
正常运行时间 99.99% (4.4m 停机/月) -> 企业层 ($$$)

单位经济学检查清单

部署任何后端服务前，计算：

  • [ ] 每请求成本：总基础设施成本 / 月请求数
  • [ ] 每用户成本：总基础设施成本 / 月活跃用户数
  • [ ] 毛利率影响：基础设施成本如何影响产品利润率？
  • [ ] 规模经济学：在10倍流量下，成本是否线性扩展或更差？
  • [ ] 盈亏平衡点：在什么流量水平下此架构回本？

架构决策 -> 业务影响

架构选择 技术效益 业务影响
CDN + Edge缓存 更低延迟 更高转化，更好SEO
读取副本 扩展读取 处理流量峰值无降级
基于队列的处理 解耦服务 高负载期间更平滑UX
多区域部署 容错 企业SLA合规
自动扩展 适当规模基础设施 更低COGS，更好利润率

后端团队的FinOps实践

  1. 标记所有资源 - 每个资源标记 team、service、environment
  2. 设置计费警报 - 在预算50%、80%、100%时警报
  3. 每周审查 - 15分钟每周成本审查会议
  4. 每月适当规模 - 检查CPU/内存使用率，缩减过度配置
  5. 非生产使用Spot/抢占式 - 开发/预演节省60-90%

参见 references/infrastructure-economics.md 获取详细成本建模、云提供商比较和ROI计算器。

导航

资源

共享实用程序 (集中模式 - 提取，不重复)

模板

相关技能

新鲜度协议

当用户询问版本敏感建议问题时，在断言“最佳”选择或引用版本前进行快速新鲜度检查。

触发条件

  • “用于[用例]的最佳后端框架是什么？”
  • “我应该使用什么进行[API设计/身份验证/数据库]？”
  • “Node.js/Go/Rust的最新情况是什么？”
  • “[REST/GraphQL/tRPC]的当前最佳实践？”
  • “[框架/运行时]在2026年是否仍相关？”
  • “[Express] vs [Fastify] vs [Hono]？”
  • “用于[数据库/用例]的最佳ORM？”

如何新鲜度检查

  1. 从 data/sources.json 开始 (官方文档、发布说明、支持政策)。
  2. 运行针对特定组件的定向网络搜索并打开发布说明/支持政策页面。
  3. 偏好官方来源而非博客用于版本和支持窗口。

报告内容

  • 当前格局：什么是稳定且广泛使用现在
  • 新兴趋势：什么正在获得吸引力（及原因）
  • 废弃/下降：什么正在失宠（及原因）
  • 推荐：默认选择 + 1-2替代方案，带权衡

示例主题（用新鲜搜索验证）

  • Node.js LTS支持窗口和重大变更
  • Bun vs Deno vs Node.js
  • Hono、Elysia和边缘优先框架
  • TypeScript的Drizzle vs Prisma
  • tRPC和端到端类型安全
  • 边缘计算和serverless模式

操作剧本