Buffalo 默认不支持多层级路径参数，因其底层 gorilla/mux 解析器将路径扁平化处理，导致 c.Param() 无法正确提取嵌套参数；实际访问 /users/123/posts/456 时 c.Param("id") 返回空而 c.Param("pid") 返回 "456"。
Buffalo 默认不支持多层级路径参数（比如 /users/:userID/posts/:postID 中嵌套两个 :param），直接写会报错或参数丢失——这不是配置问题，是它底层路由解析器对嵌套命名参数的支持有缺陷。
Buffalo 的路由参数解析限制在哪
Buffalo 使用 gorilla/mux 作为默认路由器，但它的 c.Param() 只能按注册顺序提取第一个匹配的命名参数，且不区分层级。例如注册了 r.GET("/users/:id/posts/:pid", handler)，调用 c.Param("id") 可能返回空，而 c.Param("pid") 却能取到值——因为内部解析把整个路径当作扁平字符串处理，没构建树状参数映射。
- 实际现象：访问
/users/123/posts/456时，c.Param("id")返回""，c.Param("pid")返回"456" - 根本原因：Buffalo 的
Param方法依赖gorilla/mux的Vars(r)，而后者在多级嵌套下无法正确绑定所有变量名 - 兼容性影响：即使升级到最新 Buffalo（v0.18.x），该行为仍未修复；官方 issue 中明确标记为 “won’t fix”，建议换用原生
gorilla/mux或 Gin
绕过限制的两种实操方案
不改框架、不弃 Buffalo，也能让多级参数可用。核心思路是放弃 c.Param()，改用 req.URL.Path 手动切分解析。
- 方案一（推荐）：在 handler 里用
strings.Split(c.Request().URL.Path, "/")拆路径，按索引取值
例如：parts := strings.Split(c.Request().URL.Path, "/"); userID := parts[2]; postID := parts[4] - 方案二：注册带固定前缀的子路由，再用
c.Param()分段取
先r.Group("/users").Handler(func(c buffalo.Context) { id := c.Param("id"); r.Subrouter().PathPrefix("/{postID}").Handler(...)——但 Buffalo 的Subrouter()不暴露完整 mux 接口，实际不可行，仅理论可行 - 注意：不要用
c.Param(".*")或正则捕获，Buffalo 对通配符参数的支持极弱，容易触发 panic 或 404
部署时必须关闭模板引擎和 HTML 渲染
Buffalo 默认启用 HTML 模板渲染和 asset 编译，这对纯 API 模块是冗余负担，还会干扰 JSON 响应头、引入意外中间件（如 SetContentType 强制设为 text/html）。
立即学习“go语言免费学习笔记（深入）”；
- 创建项目时务必加
--api标志：buffalo new myapi --api - 检查
app.go中是否含app.Use(middleware.SetContentType("application/json"))，若无则手动加；否则响应可能被塞进 HTML 包裹体 - 删掉
templates/目录，并确认app.ServeFiles和app.Use(assets.Middleware())已注释，避免启动时报错或监听多余路径 - 运行命令必须用
buffalo dev --port 8080，不能用buffalo serve（后者会启用生产构建流程，强制找packr和webpack）
真正卡住人的不是怎么写路由，而是 Buffalo 在 API 场景下仍残留 Web 应用的惯性设计——比如它默认把 404 渲染成 HTML 页面，而不是返回 {"error": "not found"}。你得一层层关掉这些“贴心”功能，才能让它像个干净的 API 模块跑起来。
