直接用app.Get、app.Post注册路由，配合{ id:uint64 }宏声明路径参数并用c.Params().GetUint64("id")获取，可实现真正可用的RESTful接口；PUT/DELETE需显式注册，否则返回405；{path:path}捕获子路径需手动解码。
直接用 app.Get、app.Post 等注册路由，配合路径参数宏（如 {id:uint64}）和 c.Params().Get() 提取值，就能写出真正可用的 RESTful 接口——Iris 不需要额外插件或 MVC 层来“实现” RESTful，它靠的是你对路径语义和 HTTP 方法的显式控制。
怎么写带 ID 的 GET /users/{id} 路由
路径中必须显式声明参数名和类型，比如 /users/{id:uint64}；只写 /users/{id} 会导致参数始终为零值，因为 Iris 不做隐式类型推断。
-
c.Params().Get("id")返回字符串，需手动转类型；更安全的做法是用c.Params().GetUint64("id")，但前提是路由已声明{id:uint64}，否则会 panic - 若想让非法 ID（如
/users/abc或/users/-1）直接 404，而不是进 handler 再校验，就必须用类型宏——这是编译期语义约束，不是运行时检查 - GET 路由不自动支持查询参数（query string），如
?page=1&limit=20，需用c.URLParam("page")单独取
POST/PUT/DELETE 必须显式注册，否则 405
Iris 不会默认启用所有方法，app.Post("/users", handler) 和 app.Put("/users/{id}", handler) 是完全独立的注册动作。漏掉 PUT 就意味着该路径对 PUT 请求返回 405 Method Not Allowed。
- 不要假设 “既然有 GET 和 POST，那 PUT 应该也通”——HTTP 方法必须逐个声明
- PUT 和 DELETE 的参数获取方式与 GET 一致：路径参数走
c.Params().Get()，表单或 JSON 数据走c.ReadJSON()或c.PostValue() - 如果用了
c.ReadJSON(&v)，结构体字段必须首字母大写 +json:tag，否则解析为空
怎么捕获完整子路径，比如 /files/a/b/c.txt
用 {path:path} 宏，且必须放在路径末尾，前面不能紧跟斜杠或其他参数，例如 /files/{name:path} 合法，/files/{name:path}/meta 会匹配失败。
-
c.Params().Get("name")返回的是原始 URL 编码后的字符串，如a%2Fb%2Fc.txt，不是a/b/c.txt - 需手动调用
url.PathUnescape()解码，否则按%2F切分可能出错 - 该宏不校验路径合法性，也不自动去除开头的
/，返回值就是请求中从该段开始的全部内容
为什么 MVC 模式下还要手写 Handle 绑定
Iris 的 MVC 不靠方法名或注解自动映射路径，GetByID 方法不会被自动挂到 /users/{id}；它只响应根路径（如 /users），子路径必须在 BeforeActivation 中显式调用 b.Handle("GET", "/{id:long}", "GetByID")。
- 路径参数类型要写对：
{id:long}对应int64，{id:uint64}才对应uint64，写错就拿不到值 - 状态码必须手动设：
c.StatusCode(201)或c.StatusCode(404)，MVC 不自动根据返回值设码 - 依赖注入字段（如数据库实例）需通过
app.Register()注入，且控制器结构体字段名必须与注册名一致，大小写敏感
最易忽略的一点：路径宏（如 {id:uint64}）和自定义宏（如 {oid:int min(1)}）是在路由匹配阶段起作用的，一旦匹配失败，handler 根本不会执行——这既是性能优势，也是调试盲区：如果你收不到请求，先检查路由是否被 macro 拦截了，而不是埋头查 handler 逻辑。
