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 实验性 — 采用前先评估
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 实验性 — 采用前先评估
不确定哪个场景最匹配？
进入"为什么选择 Plumego"查看更完整的团队层面判断，或先看架构页，了解哪些模块是稳定的，哪些仍在实验阶段。