什么时候不该使用 Plumego

By Leeting Yan

December 28, 2025

引言：一个负责任的框架，必须明确“不适用场景”

任何一个认真对待工程质量的框架，都必须敢于回答一个问题：

在什么情况下，你不应该使用我？

如果一个框架声称：

适合所有团队
适合所有阶段
适合所有业务

那么它几乎可以确定是不可信的。

Plumego 从一开始就不是一个“通用解”。
它是一个明确为某类工程问题而生的选择。

因此，这篇文章不是在“自我否定”，
而是在做一件更重要的事情：

明确 Plumego 的边界条件。

一、如果你的首要目标是“极快上线”，不该用 Plumego

Plumego 并不是为 MVP 速度而设计的

如果你当前项目的核心目标是：

尽快上线
尽快验证
尽快试错
尽快放弃或重来

那么你需要的，往往是：

强约定
自动生成
大量默认行为
最少的工程思考成本

而 Plumego 恰恰相反。

它会要求你：

明确项目结构
主动划分层次
显式处理错误
为未来留出边界

这些事情在 MVP 阶段通常是“负担”。

一个简单判断标准

如果你现在说的是：

“先做出来再说，反正以后肯定要重构。”

那么 Plumego 并不适合你。

Plumego 假设的是：

“这份代码，未来大概率还要被维护。”

二、如果团队 Go 基础较弱，不该用 Plumego

Plumego 假设你理解 Go，而不是“被 Go 保护”

Plumego 的设计前提之一是：

使用者对 Go 标准库是熟悉的，甚至是尊重的。

这意味着：

你理解 context.Context 的传播语义
你知道 net/http 的 Handler 模型
你能区分“框架约定”和“语言本身的行为”

如果团队成员主要是：

从其他语言临时转来
严重依赖框架封装
很少直接阅读标准库文档

那么 Plumego 可能会让他们：

写代码时不安
Debug 时无从下手
对“为什么要这样写”感到困惑

框架不是教学工具

Plumego 并不会：

教你什么是 HTTP
教你什么是 Context
教你如何组织业务

它只是在假设你已经知道这些之后，
提供一套更长期稳定的工程答案。

三、如果你强依赖“框架生态插件”，不该用 Plumego

Plumego 并不试图构建庞大生态

一些框架的核心优势在于：

大量插件
成熟中间件
开箱即用的组件市场

例如：

认证
限流
监控
配置中心
ORM 深度整合

而 Plumego 的策略是：

不绑死你，也不替你选。

这意味着：

你需要自己集成
你需要自己评估
你需要自己维护边界

一个现实判断

如果你的项目明确依赖：

某个框架生态中的“明星插件”
某种强耦合的工程体系
官方推荐的一整套解决方案

那么使用 Plumego，反而会增加你的成本。

四、如果你追求“极致少代码”，不该用 Plumego

Plumego 不追求“最少行数”

在 Plumego 中，你经常会看到：

明确的结构划分
显式的依赖传递
看起来“可以合并”的代码被刻意拆开

这是设计选择，而不是能力不足。

Plumego 更在意的是：

可读性
可维护性
可替换性
可演进性

一个关键分歧

如果你衡量一个框架好坏的标准是：

“同样功能，谁写得更短？”

那么 Plumego 几乎一定会输。

而且它从一开始就接受这一点。

五、如果你的系统生命周期明确很短，不该用 Plumego

Plumego 为“长期存在”的系统而设计

Plumego 非常适合：

内部基础服务
中台
长期运营的产品
核心系统

但如果你的系统：

生命周期只有几个月
明确是一次性项目
或者是活动型服务

那么 Plumego 提供的很多“长期价值”
在你这里是无法兑现的。

工程不是道德选择，而是成本计算

在短生命周期项目中：

明确结构 ≠ 收益
长期可维护性 ≠ 竞争力

选择 Plumego，反而可能是过度工程。

六、如果你希望“框架替你做决定”，不该用 Plumego

Plumego 不会替你思考

Plumego 的一个隐含前提是：

工程决策应由工程师负责，而不是框架。

因此，它不会：

强制你使用某种 ORM
决定你的目录结构
替你隐藏复杂性

它只是：

提供一个清晰的边界
给出一套推荐模式
保证这些模式是可持续的

一个直白的问题

如果你希望的是：

“告诉我该怎么写，不要让我想。”

那么 Plumego 不是一个友好的选择。

七、如果你需要“强一致的团队风格约束”，要谨慎

Plumego 是“骨架”，不是“规范大全”

Plumego 提供的是：

技术边界
请求模型
生命周期结构

但它不会强制你：

使用某种代码风格
采用某种 DDD / Clean Architecture
按某种模板生成所有代码

这意味着：

团队需要自律
需要补充内部规范
需要 Code Review 文化

如果你的团队需要：

极强的统一约束
非常明确的“标准答案”

那么 Plumego 可能“太自由”了。

八、如果你其实并不认同 Plumego 的价值观

这是最重要、也最容易被忽略的一点。

Plumego 的设计价值观非常明确：

克制
显式
长期主义
对复杂度保持敬畏

如果你本能地觉得：

这些太慢
太保守
太工程化
不够“现代”

那么即使技术上可行，文化上也会产生持续摩擦。

九、总结：不使用 Plumego，并不代表你做错了选择

选择一个框架，本质上是在回答几个问题：

你愿意为未来付出多少成本？
你愿意承担多少显式复杂度？
你信任框架，还是更信任自己？

Plumego 只是给出了一种非常清晰的答案。

如果你的答案不同，
那你完全不该、也不需要勉强自己使用 Plumego。

结语：知道什么时候“不用”，才是真正的工程成熟

一个成熟的工程体系，并不是到处使用同一个工具。

而是：

在正确的地方，用正确的复杂度。

Plumego 希望做到的，从来不是“被更多项目使用”。

而是：

只出现在真正适合它的地方。

如果你认真读完这篇文章，并决定“不用 Plumego”，
那恰恰说明：你做出了一个负责任的工程决策。