不适合使用 Plumego 的场景

Plumego 做出了一些刻意的权衡取舍。对某些团队和项目而言，这些取舍并不合适。在深入了解技术细节之前，请先阅读本页。如果以下任何场景描述了你的情况，其他工具可能更适合你。

你希望框架自动管理服务结构

Plumego 要求调用方显式编写启动逻辑、路由注册和中间件接入代码。如果你的团队倾向于让框架处理启动流程、注入依赖、通过约定或注解组织路由，Plumego 会显得过于繁琐。

Gin、Echo 等约定优先的工具箱更适合希望由框架管理结构的团队。

Plumego 的参考应用（reference/standard-service）定义了唯一的标准布局。当多个服务都从这个共享基线出发时，工具包的价值最大。

如果你的组织中每个服务都刻意采用不同的启动模式、路由组织和依赖接入方式，Plumego 的共享规范路径只会带来摩擦，而没有对应的收益。

Plumego 区分稳定根、受支持的参考应用和实验性扩展家族。这种区分很重要：它决定了哪些内容可以用于生产环境，哪些需要谨慎对待。

如果你的团队不需要区分稳定与实验性模块——只要包存在就足以作为采用信号——那么 Plumego 的成熟度管理机制会显得是不必要的开销。

Plumego 的稳定内核刻意保持精简，其 x/* 扩展家族覆盖了最常见的能力模式。但 Plumego 没有 Gin、Echo 或 Fiber 那样丰富的中间件和集成生态。

如果快速找到现成社区包比内核稳定性和接入可见性更重要，拥有更大生态的框架是更好的起点。

Plumego 基于 net/http 构建，不为了吞吐量而牺牲正确性或显式性。如果你的服务是高流量边缘代理或网关，原始请求吞吐性能是首要约束，那么更底层的工具包或专为吞吐优化设计的框架可能更合适。

这对大多数内部 API 和平台服务不适用——在这些场景中，瓶颈几乎从来不是 HTTP 框架。

Plumego 的价值随时间积累：显式接入在第十次 PR 和第百次入职时才体现价值。对于几周内就会丢弃的验证性原型，前期的显式成本无法收回。

这些不是劣势选择，它们解决的是不同的问题。Plumego 解决的是长期显式接入、Agent 可维护性的问题。如果这不是你的问题，请使用最合适的工具。