gin.Default()会埋雷，因其默认启用Logger和Recovery中间件：Logger高并发下阻塞式输出拖慢响应，Recovery暴露panic堆栈泄露敏感信息，且默认监听0.0.0.0:8080不符合内网安全要求。
为什么用 gin.Default() 会埋雷？
很多新手直接写 gin.Default() 启动服务，看似省事，但在企业内网资产系统这类需要长期稳定运行的场景里，它默认启用的 gin.Logger() 和 gin.Recovery() 中间件会悄悄吃掉性能和日志可控性。比如 Logger() 每次请求都格式化输出到 os.Stdout，在高并发扫描资产时可能成为 I/O 瓶颈；Recovery() 虽能防止 panic 崩溃，但错误堆栈直接打屏，不符合内网审计要求。
- 生产环境应改用
gin.New()，手动注册中间件，把日志重定向到文件或结构化 logger（如zap） - 若必须用
Default()，至少禁用控制台颜色：gin.DisableConsoleColor() - 资产系统常需记录操作人、IP、变更字段，这些无法靠默认中间件实现，得自己写
gin.HandlerFunc注入上下文
资产数据绑定该用 c.ShouldBindJSON() 还是 c.BindJSON()？
二者区别不在“能不能解析”，而在“出错时怎么处理”。c.BindJSON() 遇到字段类型不匹配或缺失必报 400 错误并中断执行；c.ShouldBindJSON() 允许你捕获错误后自行决定是否继续——这对资产管理系统很关键：比如批量导入设备时，某条记录时间格式错误，你不希望整批失败。
- 单条资产增删改用
c.ShouldBindJSON()，配合if err != nil判断，返回带具体字段名的错误信息（如"sn 字段不能为空"） - 校验逻辑别全丢给结构体 tag，例如 MAC 地址合法性、IP 段范围检查，应在绑定后单独写函数验证，避免 tag 表达力不足
- 注意
ShouldBindJSON()不会自动跳过未知字段，若前端多传了字段，得加json:"-"或用map[string]interface{}预过滤
如何让资产 API 支持按部门/状态/标签多条件组合查询？
硬编码一堆 if c.Query("dept") != "" 不仅难维护，还容易漏掉 SQL 注入或空值处理。Gin 本身不提供 ORM 查询构建能力，得靠组合设计。
- 用
c.Request.URL.Query()获取全部参数，再用 map 构建查询条件，避免重复调用c.Query() - 对字符串类字段（如部门名）做
strings.TrimSpace()再判空，防止空格导致查询异常 - 数值型参数（如状态码）必须用
strconv.Atoi()显式转换，并检查 error，否则传非数字会静默转成 0 - 标签（tags）这类多值字段建议用逗号分隔，后端用
strings.Split(c.Query("tags"), ",")解析，再做IN查询
r.Run() 监听地址写 ":8080" 在企业内网够用吗？
不够。内网资产系统常需 HTTPS、反向代理、多实例部署，裸写 r.Run() 会卡死在开发模式。
- 务必改成
r.Run("0.0.0.0:8080")，否则 Docker 容器内监听不到外部请求 - 生产环境必须配 HTTPS：
r.RunTLS(":443", "cert.pem", "key.pem")，证书路径要绝对且可读 - 如果走 Nginx 反代，Gin 需识别真实 IP：
c.ClientIP()默认取X-Forwarded-For，但得确认 Nginx 已配置proxy_set_header X-Forwarded-For $remote_addr; - 端口别写死，从环境变量读取：
port := os.Getenv("PORT")，方便 K8s Service 或 systemd 管理
资产系统的路由往往嵌套深（如 /api/v1/assets/{id}/history），别为了省事把所有 handler 堆在 main.go；分组路由 + 单独文件管理才是长期可维护的关键——这点比选什么数据库驱动更影响迭代速度。
