必须通过请求实测确认中间件执行顺序，因框架调度逻辑不同且隐式中间件参与链路；用httptest构造请求、c.log().infof打带trace id的日志、捕获bytes.buffer输出断言“→ m1 → m2 ← m2 ← m1”等洋葱模型序列。
中间件执行顺序不能靠“看代码注册顺序”来确认，必须通过请求实测——因为不同框架对 Use()、UseMiddleware()、路由级中间件的调度逻辑不同，且隐式中间件（如 Gin 的 Recovery、Buffalo 的 RequestID）会参与实际链路。
用 httptest 构造请求并捕获日志输出
标准库测试不依赖启动服务器，核心是把中间件链包装成 http.Handler，再用 httptest.NewRequest() 和 httptest.NewRecorder() 驱动它。关键点不是“有没有调用”，而是“调用顺序是否符合洋葱模型”：
- 每个中间件在入口和出口都打唯一标识日志（例如
"→ M1"/"← M1"），避免用fmt.Println—— 它不绑定请求上下文，多 goroutine 下容易乱序 - 日志必须写入
io.Writer（如bytes.Buffer），而非控制台，否则无法断言顺序 - 若中间件含
c.Abort()或提前http.Error()，需构造对应请求头/参数触发短路路径，并验证后续中间件是否真的被跳过
Gin 中 c.Next() 和 c.Abort() 对顺序的影响
Gin 的中间件执行是严格栈式：注册顺序即入栈顺序，c.Next() 是“继续往下走”，c.Abort() 是“清空剩余栈”。测试时最容易误判的是以为 Abort() 后的 fmt.Println("after abort") 不会执行——它仍会运行，只是不再调用后续中间件或 handler：
- 注册顺序为
M1, M2, M3，请求进入后依次打印→ M1→→ M2→→ M3 - 若
M2调用c.Abort()，则M3入口日志不会出现；但M2中c.Abort()后的语句仍执行，M1的出口日志也照常输出 - 测试断言应覆盖三类状态：
→ M1、→ M2、← M2、← M1存在，而→ M3和← M3缺失
Buffalo 框架要额外注意隐式中间件和静态路由绕过
Buffalo 启动时自动注入 middleware.RequestID、middleware.Logger 等，它们不在你的 app.Use() 里，但真实参与执行。调试前先加 -v 参数看全链：
- 运行
buffalo dev -v，启动日志会列出完整中间件栈，包括来源文件（如github.com/gobuffalo/buffalo/middleware/request_id.go:12） -
app.ServeFiles()默认绕过大部分中间件，若你手动给/assets/*加了中间件，需确认是否与全局链冲突——这类路径可能“看似走了中间件”，实则走的是独立文件服务分支 - 用
c.Log().Infof()替代fmt，它带 trace ID 和时间戳，能对齐同一请求的所有日志行，避免因异步写入导致顺序错乱
真正难测的不是“谁先谁后”，而是“谁根本没进链”。比如 Gin 的 router.StaticFS()、Buffalo 的 app.Resource()、Echo 的 Group().Static()，这些路径默认不经过你注册的中间件——测试前务必确认目标路径是否属于“被绕过”的那一类。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
