Gin 不支持原生解析嵌套 Map 的 Query/Form 参数，但提供 QueryMap 和 PostFormMap 方法处理一级方括号格式（如 user[name]），返回 map[string]string，不支持深层嵌套、不自动类型转换、重复 key 会覆盖、空 key 返回空 map，且需注意 Nginx 双解码等边界问题。
直接说结论：Gin 本身不支持原生解析嵌套 Map 类型的 Query 或 Form 参数（比如 user[name]、user[age]），但提供了 QueryMap 和 PostFormMap 两个专用方法，能安全提取这类结构——前提是参数名符合 key[subkey] 格式，且后端不做深度嵌套校验。
QueryMap 解析 ?user[name]=lily&user[age]=15 这类 URL 参数
当请求是 GET 方法，且前端把对象序列化成类似 /search?user[name]=lily&user[age]=15&tags[0]=go&tags[1]=web 的形式时，QueryMap 只处理一层扁平结构（即只认 user[xxx]，不认 user[profile][name]）。
-
ctx.QueryMap("user")返回map[string]string，值全为字符串类型，例如{"name": "lily", "age": "15"} - 如果 URL 中出现重复 key（如
?user[name]=a&user[name]=b），QueryMap会覆盖，只保留最后一个 - 它不会自动做类型转换，
"age"字段仍是字符串，需手动转strconv.Atoi - 若传入的 key 根本不存在（如
ctx.QueryMap("profile")），返回空 map，不会 panic
PostFormMap 处理 POST 表单里的 user[name]、user[email] 字段
对 application/x-www-form-urlencoded 类型的 POST 请求，PostFormMap 行为与 QueryMap 高度一致，但仅适用于表单提交，不兼容 JSON 或 multipart。
- 必须确保 Content-Type 是
application/x-www-form-urlencoded，否则PostFormMap返回空 map - 和
QueryMap一样，只支持一级方括号，user[address][city]会被忽略或截断为user[address] - 不能和
Bind系列混用：如果你同时调用了ctx.ShouldBind(&form)，再调PostFormMap可能读不到原始 body（因为 body 已被消耗） - 推荐搭配结构体字段 tag 使用：
type UserForm struct { Name string `form:"user[name]"` }——但这需要手动写每个字段，不如PostFormMap灵活
为什么不用 ShouldBindQuery 或 BindQuery 来处理 Map？
因为 ShouldBindQuery 只认标准 query string（id=1&name=zhangsan），遇到 user[name] 这种语法会直接失败，报错 json: cannot unmarshal object into Go value of type string 或类似 binding 错误。
-
ShouldBindQuery底层走的是 query binding，依赖结构体 tag 中的formkey 映射，不识别方括号语法 - 想用结构体绑定嵌套 Map，得自己实现自定义 binding，成本远高于直接用
QueryMap - 若前端坚持发多层嵌套（如
config[db][host]），建议改用 JSON 提交，然后用BindJSON+ 自定义 struct，更可控
容易被忽略的边界情况
实际部署中，Nginx 或某些 CDN 会默认 decode 两次 URL，导致 user[name]（即 user[name] 编码后）被错误解码成 user[name] 再次解码，变成 username ——这时 QueryMap 就找不到 key。解决方式是在 Nginx 配置里加 merge_slashes off; 并确认 client 端只 encode 一次。
另外，QueryMap 和 PostFormMap 都不校验 key 是否合法，如果前端传了 user[na"me]（含非法字符），map key 会变成 na"me，后续取值要加防御性判断。
