我也喜欢这种HandlerFuncs返回错误的模式，它更加整洁，您只需编写一次错误处理程序即可。只需将中间件与包含的处理程序分开考虑，就不需要中间件传递错误。中间件就像一条链，依次执行每个中间件，然后最后一个中间件是知道您的处理程序签名并适当处理错误的中间件。
因此，以最简单的形式，使中间件保持完全相同，但最后插入一个具有这种形式的中间件（并且不执行另一种中间件，而是执行特殊的HandlerFunc）：
// Use this special type for your handler funcstype MyHandlerFunc func(w http.ResponseWriter, r *http.Request) error// Pattern for endpoint on middleware chain, not takes a diff signature.func errorHandler(h MyHandlerFunc) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // Execute the final handler, and deal with errors err := h(w, r) if err != nil { // Deal with error here, show user error template, log etc } })}…
然后像这样包装您的函数：
moreMiddleware(myMiddleWare(errorHandler(myhandleFuncReturningError)))
这意味着这个特殊的错误中间件只能包装您的特殊功能签名，并且位于链的末尾，但这很好。另外，我会考虑将这种行为包装在您自己的多路复用器中，以使其更简单并避免传递错误处理程序，并让您更轻松地构建中间件链，而不必在路由设置中进行难看的包装。
我认为，如果您使用的是路由器库，则可能需要对此模式的显式支持。您可以在此路由器中以修改后的形式查看此示例的运行方式，该示例完全使用您要使用的签名，但是可以处理中间件链并无需手动包装即可执行：
https://github.com/fragmenta/mux/blob/master/mux.go
