0. 这份示例解决什么问题 你已经有了 Plumego，但真正把它用进“用户中心”这种业务时，通常会卡在三件事： 模块边界：User / Auth / Project 怎么拆，拆

目标与边界 你将得到一个可运行的用户中心（User Center）最小实现，覆盖： 注册：POST /api/auth/register 登录：POST /api/auth/login 刷新：POST /api/auth/refresh 当前用户：GE

状态说明 Plumego 的定位：完全基于 Go 标准库、零外部依赖、强调简单优雅与可组合。 本文为一份“可执行”的路线图提案，面向： 核心贡献者：明确优先级、版本节

定位：工程级框架文档，而不是教程集合 docs/ ├── _index.md ├── intro/ ├── getting-started/ ├── concepts/ ├── architecture/ ├── core/ ├── guides/ ├── patterns/ ├── advanced/ ├── reference/ ├── faq/ ├── roadmap/ └──

写在前面：这不是“技巧合集” 这份文档不是： API 参数的穷举说明 所有功能的使用手册 为了“写得高级”而复杂化的套路 它是一份 工程级 Best Practices

引言：为什么需要 Plumego？ 在 Birdor 的工程实践中，我们反复遇到同一个问题： 当项目从“能跑”进入“要长期维护”阶段，Go Web 框架往往开始成为负担

引言：一个负责任的框架，必须明确“不适用场景” 任何一个认真对待工程质量的框架，都必须敢于回答一个问题： 在什么情况下，你不应该使用我？ 如果一个

引言：框架对比，本质是在对比价值观 在技术社区中，“A 框架 vs B 框架”的讨论几乎从未停止。 但真正成熟的工程师往往知道： 框架之争，很少是技术对错，

前言：为什么还要再做一个 Go 框架 在 Go 生态已经高度成熟的今天，“再做一个 Go Web 框架” 看起来既多余，又无趣。 我们已经有了： 功能极其完备、社区庞大的全

写在最前：路线图不是承诺成功，而是避免自毁 在开始之前，必须先澄清一件事： 这不是一份“保证成功”的路线图，而是一份“尽量不把自己耗死”的路线图

引言：不是所有坚持都值得被歌颂 在主流叙事里，“坚持”几乎被神化了。 坚持 = 品质 放弃 = 失败 中途退出 = 不够格 但在独立开发这条路上，我必须明确告诉你

引言：独立开发真正的对手，不是市场，而是你自己 如果你已经走到第八篇，说明你很可能已经意识到一件事： 独立开发最难的部分，并不是“做成”，而是“

引言：爆款叙事，对独立开发者是一种伤害 在社交媒体上，你经常能看到这样的故事： “某某产品一夜爆红” “发布当天涌入 10 万用户” “三天做到月入 $10

引言：没赚到钱之前，你不算在“做产品” 在独立开发领域，有一句被反复自我安慰的话： “我先把用户做起来，后面再考虑变现。” 这句话听起来很理性， 但

引言：功能堆叠，是独立产品最隐蔽的自杀方式 如果你问 10 个刚开始做独立产品的开发者： “你打算怎么提升产品竞争力？” 至少有 7 个会回答： “把功能做全