buffalo默认不解析带方括号的数组参数，需用c.params().getslice("key")提取重复键值；json请求则通过结构体绑定自动解析切片字段。
Buffalo框架里数组参数默认不解析？
Buffalo 默认不会自动解析 URL 查询字符串或表单中带方括号的数组参数（比如 ids[]=1&ids[]=2 或 tags[0]=go&tags[1]=web），直接调用 c.Param("ids") 只会得到空字符串或第一个值。这不是 bug，而是 Buffalo 基于标准 net/http 的默认行为——它没启用类似 Express 或 Rails 那样的自动数组展开逻辑。
用 c.Params().GetSlice() 正确提取数组值
Buffalo 提供了专门处理重复键的 API：GetSlice()，它从底层 url.Values 中按 key 提取所有匹配值并返回 []string。这是最轻量、最可靠的方式，适用于 GET 查询和 POST 表单（application/x-www-form-urlencoded）。
常见使用场景：
- 过滤接口：/users?role=admin&role=user → 获取多个 role
- 批量操作：/api/posts?ids[]=101&ids[]=102&ids[]=103
- 前端用
FormData.append("tags[]", "rust")提交时
示例代码：
func UsersHandler(c buffalo.Context) error {
roles := c.Params().GetSlice("role") // []string{"admin", "user"}
ids := c.Params().GetSlice("ids") // []string{"101", "102", "103"}
// 转为 int64？自己 parse，Buffalo 不做类型转换
var idInts []int64
for _, s := range ids {
if i, err := strconv.ParseInt(s, 10, 64); err == nil {
idInts = append(idInts, i)
}
}
return c.Render(200, r.JSON(map[string]interface{}{
"roles": roles,
"ids": idInts,
}))
}
JSON 请求体里的数组不需要特殊处理
如果前端发的是 Content-Type: application/json，且 body 是标准 JSON（如 {"ids": [101, 102], "tags": ["go", "buffalo"]}），那 Buffalo 会通过结构体绑定自动解析数组字段，无需手动调用 GetSlice()。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
注意点：
- 必须定义对应结构体字段为切片类型（
[]int64、[]string等） - 使用
c.Bind()或c.ValidateAndBind()，不是c.Param() - URL 参数和 JSON body 是两套机制，混用时别指望
GetSlice()能读到 JSON 字段
示例结构体：
type PostFilter struct {
IDs []int64 `json:"ids"`
Tags []string `json:"tags"`
}
func FilterPosts(c buffalo.Context) error {
var f PostFilter
if err := c.Bind(&f); err != nil {
return errors.WithStack(err)
}
// f.IDs 就是 []int64，已自动解析
}
自定义解析器容易踩坑：别重写 ParseForm
有人尝试在中间件里调用 r.ParseForm() 再手动合并重复 key，这不仅多余，还可能破坏 Buffalo 内部对 multipart 表单（含文件上传）的处理流程。Buffalo 的 c.Params() 已经封装了安全的多值访问逻辑，GetSlice() 就是为此设计的出口。
真正要小心的是：
- 前端发
ids=1&ids=2（无方括号）→GetSlice()可用；但发ids[0]=1&ids[1]=2→GetSlice("ids")返回空，因为 key 是ids[0]和ids[1]，得用GetSlice("ids[0]")这种方式，显然不现实 —— 所以统一用扁平 key（ids=1&ids=2）最稳妥 - Query 和 Form 数据共存时（比如 GET + form data），
Params().GetSlice()同时包含两者，顺序不保证，业务逻辑别依赖顺序
数组参数这事，核心就一条：用对 API，别绕路。复杂点在于前后端约定格式，而不是框架本身。
