Buffalo是Go Web框架，需打包为静态二进制镜像部署到Kubernetes Pod中；禁用模板、静态文件服务和自动迁移，暴露/healthz端点并配置探针。
Buffalo 不是在 Kubernetes 集群节点上“安装”的框架——它是个 Go 语言 Web 框架，运行在容器内，不是集群基础设施组件。你真正要做的，是把用 Buffalo 写的 Go 应用打包成镜像、部署为 Pod，而不是在 node 上装 buffalo CLI 或 runtime。
buffalo build 产出的二进制怎么放进容器里？
-
buffalo build默认生成带前端 assets 和模板的胖二进制，但 Kubernetes 中应使用最小化、无依赖的纯 API 二进制 - 必须加
--static参数：GOOS=linux GOARCH=amd64 buffalo build --static
否则 macOS/Windows 构建产物无法在 Linux 容器中运行 - 构建后检查二进制是否真静态链接：
ldd yourapp应输出not a dynamic executable - Dockerfile 中不要用
FROM gobuffalo/buffalo（已废弃），改用FROM golang:1.26-alpine或scratch（若确认静态链接）
buffalo new --api 项目怎么适配 Kubernetes 生产环境？
- 删除所有非 API 相关路径：
rm -rf assets/ templates/ webpack.config.js public/
否则buffalo build会卡在 asset 编译阶段 - 注释掉
app.Use(plugins.Static())和plugins.Favicon()，避免暴露无关端点 - 禁用内置 migration 自动执行：Kubernetes 中数据库迁移应由 Job 控制，而非应用启动时触发
- 健康检查端点必须显式暴露：
app.GET("/healthz", func(c buffalo.Context) error { return c.Render(200, nil) })
并在 Deployment 中配置livenessProbe和readinessProbe指向该路径
为什么不能把 buffalo dev 或 buffalo test 带进集群？
-
buffalo dev依赖文件监听、热重载、Webpack server —— 这些在容器里既无意义又不安全 -
buffalo test是开发期命令，测试应走 CI 流水线，而非在 Pod 中运行 - 所有
buffaloCLI 工具只应在构建机（CI runner）上使用，绝不进入生产镜像 - 若镜像中误含
buffalo二进制，会增大攻击面、拖慢启动、干扰readinessProbe（因冷启动延迟高）
Kubernetes 不关心你用什么框架写服务，只关心你交付的是不是可运行、可观测、可重启的容器进程。对 Buffalo 来说，最难绕开的其实是它的设计惯性：默认绑定模板、ORM、静态文件服务。这些在集群里不是“功能”，而是累赘。删得越干净，跑得越稳。
