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 框架” 看起来既多余，又无趣。 我们已经有了： 功能极其完备、社区庞大的全

一篇面向工程团队的技术选型指南，从架构视角对比三大 JS Runtime 的特性与适用场景。 JavaScript 不再只有一个运行时，而是进入了 多 Runtime 并存的时代。 在实际业务中，如何选

理解 Node.js 的底层，必须从其运行时结构开始：事件循环、线程池、V8、libuv、模块系统与 N-API 扩展层。 下面的架构图展示了 Node.js 的完整结构，包括 JS 层到 C++ 层

理解现代 JavaScript Runtime 的核心本质。 Node.js 不仅是“让 JavaScript 跑在服务器端的工具”，它是一个完整的 Runtime，由 V8、libuv、内置调度器、事件循环、模块系统