ShouldBindJSON无法直接解析GeoJSON嵌套结构，需定义匹配结构体或用map[string]interface{}；coordinates应声明为interface{}避免类型panic；binding标签对GeoJSON语义无效，须手动校验。
ShouldBindJSON 无法直接解析 GeoJSON 的 geometry 和 properties 嵌套结构，必须手动定义匹配的 Go 结构体或用 map[string]interface{} + 类型断言，否则会静默丢失字段或 panic。
GeoJSON 根对象结构不匹配导致绑定失败
标准 GeoJSON 是一个顶层对象，必含 type 和 features（FeatureCollection）或 geometry（Feature/Geometry），但 Gin 的 ShouldBindJSON 默认期望扁平结构体。若直接绑定到 struct { Type string } ，features 字段会被忽略；若绑定到空结构体，json.Unmarshal 会跳过未知字段，不报错但数据为空。
- 错误写法：
var geo struct{ Type string }→ 只能拿到type，features消失 - 正确做法：定义完整嵌套结构体，如
FeatureCollection或Feature，并严格对应字段名和类型 - 更灵活方案：先用
map[string]interface{}解析，再按type字段分支处理Point/Polygon等几何类型
Geometry 坐标数组的类型陷阱
GeoJSON 中 coordinates 是多层嵌套数组：点是 [lon, lat]，线是 [[lon,lat], [lon,lat]]，多边形是 [[[lon,lat], ...]]。Go 没有动态维度数组，硬写 [][][]float64 易出错且难校验。
- 常见 panic：
json: cannot unmarshal array into Go value of type float64—— 因字段类型声明与实际 JSON 数组深度不一致 - 推荐做法：将
coordinates声明为interface{}，后续用reflect或类型断言判断层级，或用第三方库如geojson（github.com/paulmach/go.geojson）做安全解析 - 注意：经度在前、纬度在后，与常见 GIS 库（如 Leaflet）一致，但和部分国内地图 SDK（如高德）相反，需在入库前校验顺序
Binding 标签对 GeoJSON 验证失效
binding:"required" 在 GeoJSON 场景下基本无效。因为 features 是切片，binding 不校验切片长度；geometry 是嵌套结构，binding 不递归校验子字段；type 字段即使加了 required，只要 JSON 里存在该 key（哪怕值为空字符串），就不会触发校验失败。
立即学习“go语言免费学习笔记（深入）”；
- 真实验证需手动做：
if len(fc.Features) == 0、if f.Geometry == nil、if f.Geometry.Type != "Point" - 避免依赖
ShouldBindJSON自动返回 400：它只校验结构体字段是否存在，不校验 GeoJSON 语义合法性 - 建议封装校验函数，例如
IsValidGeoJSON(data []byte) error，用json.RawMessage预解析再分路径校验
性能敏感场景下避免重复解析
一个典型错误是在日志中调用 json.Marshal 输出原始请求体，同时又用 ShouldBindJSON 解析一次 —— 这会导致 Body 被读两次，而 http.Request.Body 是单次可读流，第二次读会返回空。
- 根本原因：
ShouldBindJSON内部已调用ioutil.ReadAll，Body 流已被消耗 - 修复方式：用
c.Request.Body = io.NopCloser(bytes.NewReader(bodyBytes))重置 Body（仅限调试），或更稳妥地——只解析一次，用json.RawMessage延迟解析properties等非关键字段 - 高频接口建议：直接读取
c.Request.Body到[]byte，然后用json.Unmarshal到结构体 + 手动校验，比ShouldBindJSON少一层封装开销
GeoJSON 处理真正的难点不在解析语法，而在字段语义一致性、坐标精度容错、以及与下游 GIS 工具链的坐标系对齐。别指望框架自动搞定这些，得靠明确的结构体定义 + 主动校验 + 清晰的错误反馈路径。
