这里是
content/posts/golang/plumego的目录页，收录 9 篇围绕 Plumego 的文章。Plumego 不是又一个要跟 Gin、Echo 抢生态的框架，它更像一次反向提问：如果我们几乎只用 Go 标准库，把路由、中间件、Context 与错误模型都摊开写在业务代码里，长期维护成本会不会更低？这 9 篇从动机、设计取舍、上手、文档结构、路线图一路讲到完整业务示例，最后专门用一篇说明它的适用边界。如果你正在为一个小而长期的 Go 服务选型，建议按下面的顺序读。
专题速览
| 维度 | 说明 |
|---|---|
| 文章规模 | 9 篇，覆盖理念、对比、上手、文档、路线图与实战示例 |
| 时间跨度 | 2025-12-28 至 2025-12-29，是一次集中的框架说明与示例产出 |
| 难度分布 | 理念与选型 3 篇、上手与文档 3 篇、工程实践与示例 3 篇 |
| 覆盖方向 | 设计哲学、框架对比、使用边界、最小示例、信息架构、路线图、分层规范、真实业务骨架 |
| 典型读者 | 需要为中小型服务做技术选型，或想理解「极简框架」设计取舍的 Go 开发者 |
| 前置要求 | 熟悉 Go 基础语法与 net/http 的基本用法 |
框架定位与设计取舍
Plumego 的核心主张是「显式优于约定、可读优于魔法、标准库优先」。这一组文章不推销框架，而是把设计动机与代价一起讲清楚：它解决了什么真实问题，又在哪些维度上主动放弃了便利性。
| 文章 | 一句话核心内容 |
|---|---|
| Plumego：一个回归 Go 本质的极简服务框架 | 从「为什么还要再做一个 Go 框架」讲起，说明以标准库为底座的设计动机 |
| Plumego vs 常见 Go 框架：设计取舍说明 | 从设计哲学、工程边界、依赖策略与长期维护成本对比主流框架，解释各自适合什么项目 |
| 什么时候不该使用 Plumego | 从工程阶段、团队结构、业务目标与风险模型出发，系统说明不适合选它的情形 |
上手路径与文档结构
决定要试之后，接下来是「怎么跑起来」和「文档从哪看」。这一组三篇构成最短的上手闭环：一篇带你写出最小可运行示例，一篇解释文档的信息架构，一篇给出能力演进的公开路线图。
| 文章 | 一句话核心内容 |
|---|---|
| Plumego 入门：一个克制而清晰的 Go 服务框架 | 从工程视角讲清设计理念、核心结构与最小可运行示例，快速建立整体认知 |
| Plumego Docs 信息架构（IA）总览 | 说明文档的组织方式与阅读顺序，让你知道遇到问题该去查哪一部分 |
| Plumego Roadmap | 以标准库、零依赖、可组合为核心，按里程碑规划 Router、Middleware、Context、WebSocket、Auth、Local DB 的演进与稳定化 |
工程实践与完整示例
看懂理念之后，真正的问题变成「落到业务里长什么样」。这一组先给出一份面向长期维护的实践指南，再用两个用户中心示例把路由、鉴权、错误模型、存储抽象与模块组织完整走一遍。
| 文章 | 一句话核心内容 |
|---|---|
| Plumego Best Practices | 基于真实项目经验总结结构设计、分层边界、Context 使用、中间件规范与演进策略 |
| 一个真实业务（用户中心）的完整 Plumego 示例 | 从 0 搭一个可运行的用户中心：注册/登录/刷新令牌、当前用户、RBAC 管理接口、统一错误与审计字段 |
| Plumego Best Practices · 一个真实业务（用户中心）的完整示例 | 以 User/Auth/Project 为例给出可落地的业务骨架：路由、鉴权、错误模型、存储抽象与模块组织 |
推荐阅读路径
路径一 先判断要不要用（30 分钟）
按 plumego-introduction → plumego-vs-go-frameworks → when-not-to-use-plumego 顺序读。三篇读完你应该能明确回答一个问题：我这个项目的团队规模、迭代节奏和风险模型，是否真的需要「少依赖、多显式」的框架。
路径二 已经决定要试（半天）
读 getting-started-with-plumego 跑通最小示例，再读 plumego-doc-arch 建立文档地图，然后读 plumego-best-practices 校准分层与 Context 用法。此时你已经可以开始写第一个真实模块。
路径三 直接抄业务骨架（一天）
跳过理念，直接从 plumego-user-center-example 与 plumego-user-center-complete-example 入手，把用户中心的注册、登录、令牌刷新与 RBAC 改成自己的业务域；遇到结构问题时回头查 plumego-best-practices，需要规划后续能力时看 plumego-roadmap。
常见误读澄清
- 「极简」不等于「功能少」：Plumego 的取舍是尽量不引入第三方依赖，而不是不提供能力。
- 「标准库优先」不等于「不能用库」：它约束的是默认路径，业务确实需要时仍然可以引入。
- 「显式」是有代价的：更多样板代码、更少的自动魔法，换来的是排查问题时更短的链路。
相关专题
| 专题 | 关联点 |
|---|---|
| Go / Golang 专题总目录 | 本目录的上级专题，含标准库、并发与工程实践长文 |
| Go 入门专题导航 | 128 篇从环境搭建到云原生的入门序列，适合作为前置阅读 |
| Go 进阶教程导航 | 151 篇主题文章，HTTP 服务端与中间件相关章节可配合阅读 |
| SaaS 专题 | 多租户与订阅制业务的架构延伸 |
| 分布式系统专题 | 服务发现、限流与一致性问题的进阶阅读 |