buffalo需用zap替代默认log：通过实现io.writer桥接器并调用setoutput()接管app.logger输出，禁用其prefix/flags；重写middlewarelogger和recover中间件，使访问日志与panic堆栈均走zap结构化输出。
Buffalo 框架默认使用 log 包（标准库）输出日志，性能弱、无结构化、不支持异步写入，直接替换为 Zap 能显著降低日志 I/O 开销，尤其在高并发 HTTP 请求场景下。但 Buffalo 并未原生适配 Zap，必须手动接管日志输出链路，否则 Zap 的高性能优势会被 Buffalo 的中间件日志逻辑绕过。
如何让 Buffalo 使用 Zap 替代默认 log 实例
Buffalo 的核心日志入口是 app.Logger，它本质是 *log.Logger 类型。不能直接赋值 *zap.Logger，会类型不匹配。正确做法是：保留 Buffalo 的日志接口契约，用 Zap 封装一个符合 io.Writer + log.Logger 行为的桥接器。
- 创建一个自定义
Writer类型，实现io.Writer接口，内部调用zap.Sugar().Infof或Debugf格式化写入 - 将该
Writer赋给app.Logger.SetOutput()，而非直接替换app.Logger - 注意：Buffalo 的
app.Logger仅用于框架自身日志（如启动、路由加载），业务逻辑日志仍需直接使用zap.Logger实例，避免混用
为什么不能直接用 zapcore.AddSync(os.Stdout) 替换 app.Logger.Out
Buffalo 的 app.Logger 是标准库 log.Logger，其 Out 字段类型是 io.Writer，看似能塞进 zapcore.AddSync(...) 返回值——但问题在于：Zap 的 WriteSyncer 不会自动格式化日志前缀（如时间、文件名、level），而 log.Logger 默认会在每条输出前加 [INFO] 这类前缀；两者叠加会导致日志内容重复或错乱，例如：[INFO] {"level":"info","msg":"request completed"}。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- Buffalo 的
log.Logger自带 prefix 和 flag（如log.LstdFlags），Zap 的 JSON encoder 不识别这些 - 若强行注入，Zap 输出的 JSON 会被
log.Logger当作纯字符串再套一层前缀，破坏结构化 - 真正安全的做法是：禁用
app.Logger的所有 prefix 和 flags，再用自定义Writer把原始字节流转成 Zap 的结构化字段
如何让请求中间件日志也走 Zap（比如 access log）
Buffalo 的 buffalo.MiddlewareLogger 默认用 app.Logger 打印访问日志，它只接受 log.Logger，不支持传入 zap.Logger。要让它输出结构化日志，必须重写该中间件逻辑。
- 复制
buffalo.MiddlewareLogger源码，把内部app.Logger.Printf调用替换成zapLogger.Info("http.access", zap.String("method", r.Method), zap.String("path", r.URL.Path), ...) - 关键字段（status、latency、size）必须从
ResponseWriter包装器中捕获，不能依赖log.Printf的字符串拼接 - 避免在中间件里频繁调用
zapLogger.With(...)创建新实例，应复用全局 logger 或用Sugar提升性能 - 如果用了
lumberjack做日志轮转，确保该中间件写入的是同一个WriteSyncer，否则文件切割不同步
最易被忽略的一点：Buffalo 的错误恢复中间件（Recover）默认用 log.Printf 打印 panic 堆栈，这部分日志完全游离在 Zap 体系之外。必须手动拦截 recover() 后的 err，用 zapLogger.Error("panic recovered", zap.String("stack", string(debug.Stack()))) 显式记录，否则线上 panic 会丢失上下文。
