c.ShouldBindJSON报“invalid character”错误主因是前端未设Content-Type: application/json、发送空/空白/表单格式数据，或Nginx代理篡改头；应优先用ShouldBindJSON并配合io.ReadAll调试原始body，而非依赖自动解析。
为什么 Gin 的 POST 接口收不到前端传的 JSON 数据
常见现象是 c.ShouldBindJSON(&req) 返回 invalid character 或直接 panic，其实多数不是代码写错，而是前端没发对格式，或者 Gin 没配好中间件。
关键点有三个：
- 前端必须设置
Content-Type: application/json，否则 Gin 默认按form解析，ShouldBindJSON会失败 - Gin 默认已注册
gin.Recovery()和gin.Logger()，但JSON解析依赖gin.Default()内置的gin.Binder，不能手动替换gin.New()后忘了加gin.JSONBinding - 如果用了 Nginx 反向代理，要确认它没截断或重写
Content-Type或Content-Length，尤其在测试环境用curl -H "Content-Type: text/plain"模拟时容易误判
验证方式：在 handler 开头加 body, _ := io.ReadAll(c.Request.Body); log.Println(string(body))，看原始字节是否为合法 JSON。
c.BindJSON 和 c.ShouldBindJSON 该选哪个
区别不在功能，而在错误处理策略——c.BindJSON 遇错直接返回 400 并终止后续逻辑；c.ShouldBindJSON 把错误交给你自己判断，适合需要统一日志、审计或降级响应的场景。
立即学习“go语言免费学习笔记（深入）”；
小微企业收银台接口通常要求明确反馈错误类型（比如“金额格式错误”“订单号重复”），不建议用 BindJSON：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
c.ShouldBindJSON(&req)返回err后，可检查errors.Is(err, json.UnmarshalTypeError)做字段级提示 - 若需兼容部分字段缺失（如优惠券 ID 可空），结构体字段加
json:",omitempty"，但注意int类型零值（0）也会被忽略，应改用*int - 收银台涉及金额，务必用
float64或更稳妥的string接收再转decimal.Decimal，避免浮点精度丢失
如何安全校验收银台的关键字段（金额、签名、时效）
小微商户最常被绕过的不是密码，而是时间戳和签名——攻击者复制一次请求重放，就能重复扣款。
校验链必须串行且不可跳过：
- 先检查
req.Timestamp是否在当前时间 ±5 分钟内，用time.Now().Unix()对比，别用time.Parse解析字符串再算差值（时区易错） - 签名验证必须放在绑定之后、业务处理之前；推荐 HMAC-SHA256，密钥从环境变量读取（
os.Getenv("PAY_SECRET")），不要硬编码 - 签名原文拼接顺序必须严格约定，例如：
req.OrderID + req.Amount + req.Timestamp + req.Nonce，其中Nonce是前端每次请求生成的随机字符串，服务端需缓存最近 2 分钟内的Nonce防重放
注意：Gin 中间件里做这些校验时，c.Next() 前不要调用 c.Abort() 后又继续执行，容易漏掉状态码或响应体。
并发扣款时怎么避免超卖（比如同一订单被多次支付）
收银台接口本质是“状态跃迁”：从 unpaid → paid。Gin 本身不解决并发，得靠数据层配合。
最轻量可行的做法是数据库乐观锁 + 唯一约束：
- 订单表加字段
status TINYINT DEFAULT 0（0=待支付，1=已支付），并建唯一索引UNIQUE KEY uk_order_id (order_id) - 更新语句写成
UPDATE orders SET status = 1 WHERE order_id = ? AND status = 0，用sql.Result.RowsAffected()判断是否更新成功 - 如果
RowsAffected == 0，说明已被其他请求抢先支付，此时返回409 Conflict和提示“订单已支付”，而不是重试或报错
别用 Redis 分布式锁来控单笔订单——对小微企业来说，MySQL 的 UPDATE ... WHERE 足够快且可靠；Redis 锁只适合跨服务协调（比如库存预占），反而增加复杂度和故障点。
