开篇
goframe是一款模块化、高性能、企业级的Go基础开发框架。虽然goframe不像Gin那么出名，但goframe用下来的感受是非常舒服的。它有全中文的官方文档，开发团队与用户之间保持了良好沟通，对用户的信息及时反馈。goframe开发团队一直在积极地进行维护和更新，近期推出的goframe2.0版与之前1.16版有很大的提高与变动。
在此我打算跟大家分享一下我对goframe2.0标准路由的使用心得，如有不妥欢迎留言讨论。
api请求结构体Meta
写标准路由首先要写请求结构体与响应结构体，对api请求与响应接口进行描述。先来看代码模板里的请求结构体：
type HelloReq struct {
g.Meta `path:"/hello" tags:"Hello" method:"get" summary:"You first hello api"`
}
在这段代码中可以看到在请求结构体中有路由地址、请求方法、接口描述、标签分类等信息，内容如下：
tags：接口分类标签(重要)
tags是标签分类信息，tags相同的api会合并在同一标签下展示。tags是对数据表的描述，是多个对同一张表进行不同操作的api共同使用的分类标签。
请看下图红色方框圈住的部分，通知管理tags下有4个api，分别是增删改查，4个api的共同特征是它们都是对Notice通知表进行操作，那么应该将这4个api的请求结构体tags都写成“通知管理”，这样这4个api会归在一起。
summary：接口详情描述(重要)
summary是api执行的动作描述，说明api做了什么动作。
请看上图，通知管理下有4个api，分别是增删改查。
NoticeAdd函数做的工作是新增通知，那么它的summary推荐的写法是“新增”；
NoticePut函数做的工作是修改通知，那么它的summary推荐的写法是“修改”；
其他的以此类推，不再赘述。
path：路由名(强烈不推荐)
path是api的路由名。但我极其不推荐在请求结构体里写path，具体原因有下面两条：
一是在请求结构体里写path很容易造成路由冲突。假设某个函数的请求结构体的路由是/get，另一个函数在路由表中也是/get，若它们在同一级路由下(假设都在/api下)就会造成路由冲突，造成项目启动失败。
二是path分散在不同的请求结构体中写，以后修改起来很麻烦，可维护性差。
method：请求方法(不推荐)
method是请求方法，例如get、post、put等等。但我也不推荐在请求结构体中写method，因为在请求结构体里写没有代码提示，在路由表中函数中写有代码提示。