delete路由必须显式注册为app.delete()，路径需含:id等参数定义，id须校验类型与存在性，删除前应查询资源是否存在，建议返回200+json而非204，并注意并发事务控制。
DELETE路由必须显式注册，不能靠方法重载自动识别
Fiber默认不会像某些框架那样根据HTTP方法自动映射到同名函数；app.Delete() 是独立的注册入口，漏写或误写成 app.Get() 就会导致404。常见错误是照着CRUD模板复制粘贴时只改了处理逻辑，忘了改注册方法。
- 必须用
app.Delete("/users/:id", handler)，不是app.Post()或app.Delete("/users", handler)（路径带参数才对） - 路径参数如
:id需在路由字符串中明确定义，Fiber不会从请求体或查询参数里自动提取 - 如果前端发的是
DELETE /users?id=123，后端得用c.Query("id")读取，但更推荐 RESTful 风格：用/users/123+c.Params("id")
如何安全获取并校验ID参数
直接调 c.Params("id") 拿到的是字符串，不校验就进数据库操作极易引发SQL注入或类型错误。尤其当ID是数字型主键时，必须转为整数并检查有效性。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 用
id, err := strconv.Atoi(c.Params("id"))转换，err != nil说明参数非法，应返回400 - 若ID是UUID，改用
uuid.Parse(c.Params("id"))，别用正则硬匹配 - 不要跳过校验直接拼SQL——哪怕用ORM，也要先确认
id > 0或len(id) == 36等基本约束
删除前务必检查资源是否存在，避免静默失败
直接执行 DELETE FROM users WHERE id = ? 并返回204，前端可能误以为删除成功，实际是没找到记录。用户得不到反馈，调试时也难定位问题。
- 先查一次：用
db.First(&user, id).Error（GORM）或等效查询，record not found错误要显式返回404 - 如果ORM支持，优先用
db.Unscoped().Where("id = ?", id).Delete(&User{})配合软删除逻辑，但需确保业务允许 - 删除成功后建议返回200 + JSON
{"deleted": true, "id": 123}，比204更利于前端判断状态
事务与并发删除需手动控制
Fiber本身不管理数据库事务，多个并发DELETE请求删同一行时，可能出现“幻读”或重复响应。比如两个请求同时查到记录存在，先后执行删除，第二个会删空行但无报错。
- 用数据库行锁：PostgreSQL加
SELECT ... FOR UPDATE，MySQL用SELECT ... FOR UPDATE（需InnoDB） - 或应用层加分布式锁（如Redis SETNX），但要注意锁超时和释放时机
- 更简单稳妥的做法：删完再查一次，确认记录已不存在，否则返回冲突（409）
