请求流程

请求流程

Plumego 让 HTTP 路径从路由注册到响应写出都保持可见。核心检验很简单：维护者应该能指出每一步由哪个文件或包负责。

流程图

1routes.go一个 method、一个 path、一个 handler

2core路由表和中间件链

3routermethod、path、params、groups

4middlewarerequest ID、trace、日志、限流

5contractWriteResponse 或 WriteError

1

注册路由

一个 method、一个 path、一个 handler

2

挂到应用

路由表和中间件链

3

匹配请求

method、path、params、groups

4

运行传输包装层

request ID、trace、日志、限流

5

处理并写回

WriteResponse 或 WriteError

reference/standard-service/internal/app/routes.go
  -> core route registration
  -> router method/path match
  ->传输层middleware chain
  -> net/http handler
  -> contract.WriteResponse 或 contract.WriteError

每一步负责什么

步骤	表面	负责	不应该负责
路由注册	internal/app/routes.go	一个 method、一个 path、一个 handler	隐藏 handler 发现
匹配	router	method/path 匹配、params、groups、reverse routes	业务 DTO 组装
包裹	middleware	request ID、trace、日志、限流等传输层行为	service lookup 或功能 wiring
处理	func(http.ResponseWriter, *http.Request)	解码输入、调用显式应用代码、选择成功或错误	框架专属 handler contract
写出	contract	规范成功与错误响应形态	功能专属 helper 家族

最小处理器地图

func (h APIHandler) Greet(w http.ResponseWriter, r *http.Request) {
    name := r.URL.Query().Get("name")
    if name == "" {
        _ = contract.WriteError(w, r, contract.NewErrorBuilder().
            Type(contract.TypeRequired).
            Detail("field", "name").
            Message("name is required").
            Build())
        return
    }
    _ = contract.WriteResponse(w, r, http.StatusOK, greetResponse{Message: "hello, " + name}, nil)
}

Review 检查表

问题	去哪里检查
这个 endpoint 在哪里注册？	reference/standard-service/internal/app/routes.go 或应用自己的 route 文件
它前面经过哪些 middleware？	handler 外层的 app/core 接线
依赖在哪里创建？	应用构造函数，而不是 request context 里的 service lookup
响应形态由谁决定？	成功走 contract.WriteResponse；错误走 contract.WriteError
是否仍兼容标准库？	handler 参数仍是 http.ResponseWriter 和 *http.Request

Plumego 避免的模式

避免的模式	原因
通过 init() 注册 handler	endpoint 归属难以审查
context service locator	把依赖 wiring 藏进请求状态
功能专属响应 helper 家族	拆散规范传输合约
middleware 拼业务 DTO	模糊 transport 与应用归属

建议和这些页面一起读

• 开始使用
• 参考应用
• 仓库边界