buffalo new --api 生成的项目仅为开发骨架，非生产级api内核，需删减前端冗余、替换路由器、独立管控数据库连接池与迁移、显式声明中间件顺序，并统一错误格式。
buffalo new --api 生成的项目不等于生产级API内核
直接用 buffalo new myapp --api 创建的项目只是骨架，缺编译产物控制、中间件链定制、错误统一格式、健康检查端点等企业必需项。它默认带前端模板和Webpack构建逻辑，而纯API服务根本不需要这些——反而会拖慢构建、增加攻击面、干扰CI/CD流程。
关键动作是删减冗余：移除 assets/ 目录、清空 webpack.config.js、注释掉 app.Use(plugins.Favicon()) 和所有 templates/ 渲染调用。否则 buffalo build 会卡在 asset 编译阶段，且 buffalo dev 启动时仍加载无用中间件。
- 检查
app.go中是否残留app.Use(plugins.Static())—— API 服务不该暴露静态文件 - 确认
go.mod里没引入github.com/gobuffalo/plush或github.com/gobuffalo/packr/v2—— 这些是模板和资源打包依赖，纯 JSON API 不需要 -
buffalo build前务必运行GOOS=linux GOARCH=amd64 buffalo build --static，避免本地 macOS 构建产物无法在 Linux 容器运行
路由定义必须脱离 app.GET() 硬编码方式
企业级 API 要求路由可配置、可灰度、可审计。app.GET("/users", UsersList) 这类写死在代码里的路由，上线后改路径就得发版，无法做动态路由或 A/B 测试。Buffalo 的 routes/app.go 是入口，但不应成为唯一路由源。
推荐方案：用 gorilla/mux 替换默认路由器，在 app.go 初始化阶段注入自定义 http.Handler，再把 Buffalo 的 action handler 封装成标准 http.HandlerFunc 注册进去。这样既能复用 Buffalo 的 Context 和中间件机制，又能外挂路由规则（比如从 etcd 加载）。
- 别直接修改
app.Routes()返回值——它是只读的，强行赋值会导致 panic - 若要用 Buffalo 内置路由，至少把 path 拆成常量：定义
const UserListPath = "/api/v1/users"，避免散落在各处的字符串字面量 - 所有路由必须带版本前缀（如
/api/v1/），Buffalo 默认不校验，需手动在app.Use()中加中间件拦截非 v1 请求并返回 404
数据库连接池与迁移必须独立管控
Buffalo 自动生成的 database.yml 和 buffalo db migrate 在开发期方便，但企业环境要求连接池参数可调、迁移脚本可回滚、失败时有明确 exit code。默认行为会掩盖连接超时或锁表问题。
实际做法是绕过 buffalo db CLI，改用 GORM 或 sqlx 直接管理连接，并把 migration 拆为独立二进制命令（如 ./migrate up）。Buffalo 的 pop 库已多年未更新，对 PostgreSQL 15+ 的分区表、JSONB 索引支持滞后，且不兼容 Go 1.22 的泛型约束。
- 禁用
pop.Connection，改用sql.Open("postgres", dsn)手动设置db.SetMaxOpenConns(20)和db.SetConnMaxLifetime(1h) - 迁移文件不要放在
models/migrations/下——Git 分支合并时易冲突；改用migrations/20240101_create_users.up.sql+.down.sql格式，由外部工具执行 - 在
actions/app.go的app.Serve()前加健康检查：尝试db.PingContext(ctx)，失败则os.Exit(1)，让 Kubernetes readiness probe 快速发现
中间件链必须显式声明顺序，不能依赖 app.Use() 默认顺序
Buffalo 的中间件注册看似简单，但 app.Use(mw1); app.Use(mw2) 实际执行顺序是反向的（mw2 先于 mw1），且内置中间件（如 session.Sessions()）会插在中间，导致日志、鉴权、CORS 行为不可预测。企业 API 要求中间件顺序绝对可控。
解决方案是放弃 app.Use()，改用标准 http.Handler 链式包装：h := mwAuth(mwLog(mwCORS(app.Handler)))。Buffalo 的 app.Handler 是最终的 http.Handler，把它当底层 endpoint 封装即可。
- 别在
app.Use()里传入匿名函数——调试时无法定位中间件名，日志也只显示func - CORS 中间件必须显式指定
AllowedOrigins，handlers.AllowedOrigins([]string{"https://admin.example.com"})，禁止用*，否则带 credentials 的请求会被浏览器拦截 - 错误中间件要覆盖
buffalo.ErrorHandler，统一返回{"code": 40001, "message": "invalid parameter", "trace_id": "xxx"}格式，而非默认的 HTML 页面
buffalo dev 的便利性误当作生产就绪信号——真正难的是连接池抖动时的自动熔断、百万级日志下的 trace ID 透传、以及升级 Buffalo minor 版本时 pop 库 silently 改变 SQL 生成逻辑。这些细节不会出现在任何 quickstart 文档里。大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
