good fit
你的团队想要可见的结构，而不是框架约定
Plumego 适合那些希望 route ownership、中间件顺序和依赖 wiring 都写在代码里的团队——而不是交给框架注册机制管理。
使用场景
场景到模块的映射
假设你已决定使用 Plumego。本页将具体服务场景映射到对应的模块、需要确认的适配信号，以及每种场景的最佳起步页面。如果你还在评估是否适合，请先看「为什么选择 Plumego」。
七个显式 wiring 最有价值的场景。
当服务形态需要在代码库增长后依然保持可读、多团队需要从同一基线起步、或者能力工作应当留在 HTTP 内核之外——Plumego 的拟合度最强。
good fit
你需要一个在能力演进时保持兼容的稳定内核
稳定根承担长期兼容性承诺。能力工作从 x/* 家族起步，内核就不会吸入每一项快速演进的工作。
slow down
你希望框架自动管理结构，不需要手动写 wiring
如果团队更希望路由和依赖注入被框架默认处理，Plumego 可能会显得过于显式。
场景详解。
每张卡片说明涉及的能力模块、要验证的适配信号，以及该场景最合适的起步页面。
internal api
需要在评审中直接看清 route ownership 的内部 HTTP 服务
当一次 PR 应该让 reviewer 看清哪些路由被注册、哪些中间件按序执行、依赖由谁持有——而不需要先读框架源码——Plumego 更合适。
- reviewer 很关注服务边界
- bootstrap 与 handler ownership 需要保持直观
- 团队已经习惯在 net/http 心智下工作
模块： core, router, contract, middleware 仅限稳定根
platform service
多团队共用同一套 canonical 服务形态的平台服务
当新服务应该从同一份可读的参考布局起步，而不是每个团队各自写 bootstrap，Plumego 是最强的。用同一套 canonical 起点，结构漂移就能保持在低水位。
- 新服务继承相同的目录与 wiring 形态
- reviewer 只接受一小组明确的跨服务模式
- 团队轮转时 onboarding 成本可以保持低
模块： reference/standard-service canonical 参考
multi-tenant saas
带强制租户路由、配额与策略的多租户 SaaS 服务
当服务需要 JWT 租户身份、per-tenant 配额执行和策略评估，且这些逻辑应该在 HTTP 内核之外——就用 x/tenant。稳定根承担 HTTP 基线，x/tenant 承担租户层，两者互不污染。
- 租户身份来自 JWT 或 header，在传输层评估
- per-tenant 配额与策略与 route wiring 分开
- 租户逻辑演进时，稳定根保持兼容
模块： x/tenant beta — 次要版本之间 API 冻结
ai service
带 streaming、provider 管理和工具路由的 AI 能力服务
当你需要多 provider 抽象、session 生命周期、streaming 响应处理和 tool-call 路由，同时还要保持稳定 HTTP 内核，就用 x/ai。稳定根保持传输层兼容，x/ai 承接快速演进的 AI 能力工作。
- AI provider 抽象与 HTTP 传输保持分离
- streaming 响应通过标准 net/http handler 处理
- AI API 形态演进时，稳定根保持兼容
模块： x/ai 实验性 — provider/session/streaming/tool 子表面为 beta，父家族仍在评估
api gateway
带负载均衡与边缘路由的反向代理与 API 网关服务
当你的服务需要把请求代理到上游后端、应用改写规则或在多个目标之间负载均衡，就用 x/gateway。稳定 HTTP 内核负责传输层，x/gateway 承担代理与边缘行为层。
- 上游代理与改写规则留在 HTTP 内核之外
- 负载均衡与后端发现在配置里显式声明
- 稳定中间件在转发前完成鉴权与限流
模块： x/gateway beta — 次要版本之间 API 冻结
real-time service
带 WebSocket hub、房间与广播的实时服务
当服务需要在标准 HTTP 路由旁维护长连接、房间管理与广播能力，就用 x/websocket。WebSocket handler 与标准 HTTP 路由一起显式注册；稳定内核不会去理解 WebSocket 语义。
- WebSocket 路由与标准 HTTP 路由并列注册
- hub 生命周期与房间管理独立于 HTTP handler 逻辑
- 稳定传输中间件在 WebSocket 升级前先生效
模块： x/websocket beta — 次要版本之间 API 冻结
messaging service
把队列、webhook 与定时任务整合进 HTTP handler 的消息服务
当你的服务需要在 HTTP 路由旁分发或消费任务、外发 webhook、pubsub 事件或定时任务，就用 x/messaging。面向应用的服务层是 beta；子级原语（mq、pubsub、scheduler）仍为实验性。
- 消息分发与消费独立于 HTTP handler 逻辑
- 定时任务与外发 webhook 作为服务依赖显式声明
- 稳定传输层负责路由，与消息层解耦
模块： x/messaging beta — 应用层服务已冻结；子级原语仍为实验性
仓库中真实的项目。
这些是 use-cases/ 目录下可运行的用例。每一个都把上面的抽象场景落到具体 Go 模块——在决定复制哪种服务形态之前，先看看源码。
multi-tenant saas
use-cases/mini-saas-api
一个有边界的多租户 SaaS API 示范——在 Plumego 稳定根之上实现租户隔离、配额执行和 JWT 策略。
对应场景： 多租户 SaaS
状态： 参考用例
ai + storage
use-cases/cloud-vault
面向 AI 生成笔记的 local-first Markdown 知识库。演示 x/data + x/frontend 在 standard-service 基线上的组合。
对应场景： 内部 API + AI 服务
状态： 参考用例
admin plane
use-cases/dbadmin
本地优先、注重安全的数据库工作台（MySQL / Postgres / SQLite / Redis / MongoDB / Elasticsearch）——展示 Plumego 如何承载带敏感连接的运维平面服务。
对应场景： 平台服务
状态： 参考用例
monitoring
use-cases/guardus
在 Plumego 稳定根 + x/observability 之上对 Gatus（健康/状态监控）的 v1 功能等价重实现。
对应场景： 平台服务
状态： 参考用例
depth exploration
use-cases/workerfleet
仍在推进中的 worker 机队监控服务，用于探索超出 canonical 服务深度的形态——MongoDB 存储、Kubernetes Pod 发现、Prometheus 指标以及告警/通知流水线。部分方法仍返回 ErrNotImplemented。
对应场景： 平台服务 + 消息
状态： 进行中
不确定哪个场景最匹配？
进入"为什么选择 Plumego"查看更完整的团队层面判断，或先看架构页，了解哪些模块是稳定的，哪些仍在实验阶段。