GoFrame框架中HookAfterOutput阶段读取请求体的注意事项

问题背景

在使用GoFrame框架开发Web应用时，开发者可能会遇到在HookAfterOutput阶段读取请求体导致panic的问题。这种情况通常发生在没有预先解析请求体的情况下，在响应输出后尝试读取请求体内容。

问题现象

当开发者在HookAfterOutput钩子函数中调用GetBody()方法时，如果之前没有解析过请求体，程序会抛出panic。这是因为在响应输出阶段，框架已经关闭了请求连接并丢弃了请求体内容。

技术原理

GoFrame框架在处理HTTP请求时，请求体会在特定阶段被解析和缓存。如果在业务逻辑中没有调用GetBody()方法，请求体将不会被缓存。当响应输出完成后(HookAfterOutput阶段)，底层的网络连接已被关闭，此时再尝试读取请求体就会导致panic。

解决方案

1. 预先解析请求体

在业务逻辑中显式调用GetBody()方法，确保请求体被正确解析和缓存：

func handler(r *ghttp.Request) {
    // 预先解析请求体
    r.GetBody()
    // 其他业务逻辑
}

2. 区分框架404和业务404

当需要区分路由不存在(框架404)和业务数据不存在(业务404)时，可以使用上下文变量标记业务错误：

// 业务逻辑中
func businessHandler(r *ghttp.Request) {
    if dataNotFound {
        r.SetCtxVar("businessError", true)
        r.Response.WriteStatus(http.StatusNotFound)
        return
    }
}

// Hook函数中
func hookFunc(r *ghttp.Request) {
    if r.Response.Status == http.StatusNotFound && !r.GetCtxVar("businessError").IsEmpty() {
        // 处理业务404
    } else if r.Response.Status == http.StatusNotFound {
        // 处理框架404
    }
}

最佳实践

1. 尽早解析请求体：如果需要在Hook中访问请求体，确保在中间件或业务逻辑中预先解析。

2. 合理使用上下文变量：通过SetCtxVar/GetCtxVar方法传递业务标记，帮助后续处理逻辑区分不同场景。

3. 错误处理规范化：为业务错误定义统一的错误码和错误处理机制，避免与框架状态码混淆。

4. 日志记录完整：在Hook中记录请求信息时，注意检查请求体是否可用，避免panic。

总结

理解GoFrame框架请求处理的生命周期对于避免这类问题至关重要。开发者应当注意请求体的解析时机，合理设计错误处理机制，确保应用稳定运行。通过上下文变量传递业务标记是一种灵活且有效的解决方案，可以帮助区分框架行为和业务逻辑。