Buffalo 默认日志输出到 stdout 而非文件，且未暴露 zap 配置入口；持久化推荐进程级重定向（如 tee、systemd 或 Docker 日志管理），而非修改代码。
Buffalo 默认不把日志写入文件，它直接输出到 stdout（终端），所以你运行 buffalo dev 时看到的日志只是控制台打印，关掉进程就没了。要持久化日志，得手动接管日志输出目标。
Buffalo 的日志底层是 zap，但没暴露配置入口
Buffalo 内部用的是 github.com/uber-go/zap，但它的日志实例（buffalo.Logger）在启动时硬编码为 console writer，没有开放 zap.Config 或 zapcore.WriteSyncer 的配置点。你不能靠改 app.go 或环境变量直接切到文件输出。
- 试图在
app.go里调用buffalo.WithLogger(...)无效——该函数只影响中间件层日志，不覆盖框架启动、迁移、服务器监听等关键日志 -
LOG_LEVEL环境变量只控制日志级别（debug/info），不影响输出位置 - 第三方日志库（如
logrus）无法自动替代 Buffalo 内部 logger，因为很多日志发生在框架初始化阶段，早于你代码执行
推荐做法：用 os.Stdout 重定向 + 进程管理工具
最轻量、最可靠的方式不是改 Buffalo 源码或打补丁，而是让整个进程的标准输出落地为文件。这符合 Unix 哲学，也避免侵入框架逻辑。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 开发时：
buffalo dev 2>&1 | tee buffalo.log—— 实时看屏+落盘，适合调试 - 生产部署（systemd）：
StandardOutput=append:/var/log/buffalo/app.logStandardError=append:/var/log/buffalo/app.log
并配RotateSize=10M和MaxFileSec=30day - Docker 场景：挂载卷 +
docker logs -f查看，日志由 Docker daemon 统一管理，无需应用层写文件
如果真要代码层写文件，必须替换 http.Server 的 logger
Buffalo 启动的 HTTP server（http.Server）自带 Log 字段，它控制访问日志（404、500、请求耗时等）。这个字段可被替换，但仅限这部分日志：
// 在 app.go 的 App() 函数末尾添加
f, _ := os.OpenFile("access.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
server := http.Server{
Handler: app,
Log: log.New(f, "", log.LstdFlags),
}
// 然后用 server.Serve(...) 替代默认启动逻辑
- 这个
Log只捕获 HTTP 层错误和访问记录，不包括 Buffalo action 执行日志、migration 输出、模板渲染错误等 - 注意文件未做 rotate，长期运行会撑爆磁盘；需额外引入
gopkg.in/natefinch/lumberjack.v2封装io.Writer - 这样做后，
buffalo dev命令失效，必须改用自定义构建的二进制启动
真正麻烦的不是“怎么写入文件”，而是 Buffalo 把日志职责拆太散：框架启动日志、HTTP server 日志、action 内部 c.Logger()、Pop 数据库日志各自独立，没有统一日志门面。想全量捕获，只能靠进程级重定向——这点容易被文档忽略，但实际项目里最省心。
