buffalo dev 不是调试器，因其启动多层封装子进程导致断点不命中、panic被recovery捕获、dlv连接不稳定；应改用 dlv exec ./main.go 直连调试，配 mode: "exec" 并确保 app.Serve() 可达。

buffalo dev 不是调试命令，它不支持断点、看不到 panic 原始堆栈、无法步进 handler 逻辑——真要调试，必须绕过它。

为什么 buffalo dev 不能当调试器用

它启动的是带多层封装的子进程：文件监听器、重建脚本、日志包装器、recovery 中间件全裹在一起。结果就是：

• 在 actions/home.go 里设的 Delve 断点根本不会命中
• panic 被 recovery 中间件捕获，终端只打印 Internal Server Error，没行号也没调用栈
• log.Printf("here") 能输出，但调试器连不上运行时
• 改代码触发自动重启后，dlv 连接直接断开，得手动重连

用 go run + dlv 直接跑 main.go

这才是可控的调试路径：跳过 CLI 封装，让调试器直连 Go 进程生命周期。

Buffalo框架 1.0.1

Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。

下载

• 确保 main.go 里有 app.Serve() 调用，且没被 //go:generate buffalo dev 这类标记干扰
• 终端执行：dlv exec ./main.go --headless --api-version=2 --accept-multiclient --continue
• 另开终端，用 VS Code 或 GoLand 连 :2345，或直接 dlv connect :2345
• 在 actions/app.go 的 App() 函数开头、或具体 handler 行设断点，例如：break actions/home.go:12

VS Code launch.json 必须配 "mode": "exec"

别用 launch 或 test 模式，它们会尝试编译再运行，断点重载不可靠。

• 配置中 "program" 指向 ${workspaceFolder}/main.go，不是二进制
• "env" 里显式传关键变量，比如："APP_ENV": "development"、"DATABASE_URL": "postgres://localhost/myapp_development?sslmode=disable"
• 删掉所有 args 或留空数组，避免误触发 CLI 解析逻辑

真正麻烦的从来不是“怎么连上”，而是连上之后发现 app.Serve() 被包在 if err != nil { log.Fatal(err) } 里——panic 就这么被吞了，你看到的只是进程退出。动手前先翻一遍 main.go。