引言：一个负责任的框架，必须明确“不适用场景”
任何一个认真对待工程质量的框架，都必须敢于回答一个问题：
在什么情况下，你不应该使用我？
如果一个框架声称：
- 适合所有团队
- 适合所有阶段
- 适合所有业务
那么它几乎可以确定是不可信的。
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”，
那恰恰说明：你做出了一个负责任的工程决策。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。