编码规范
· 不需要注释实现接口的方法
代码格式
可以使用gofmt自动化格式代码
注释
· 解释代码作用（对功能进行说明）
· 解释代码如何做的（对不明显的逻辑进行解释，从全局对代码的做法进行解释）
· 解释代码实现的原因（提供额外上下文的信息）
· 解释代码在什么情况会出错（调用该代码的限制条件）
公共符号始终要注释
命名规范
-variable:
· 简洁胜于冗长(index -> i)
· 缩略词必须全大写，当其位于变量开头且不需要导出时，用全小写(ServeHTTP)
· 变量距离其被使用的地方越远则需要携带越多上下文信息
tips：t常代指任意时间、取名尽可能降低变量名的信息量(t -> deadline)
-function:
· 函数名不携带包名的上下文信息，因为两者总是成对出现
· 函数名尽量短
func Serve(I net.Listener,handler Handler) error 这样调用的时候就可以直接Http.Serve
-package
· 只有小写字母构成，不包含大写字母和下划线字母
· 简短并包含一定的上下文信息。例如schema、task
· 不要与标准库同名，例如不要用sync或者strings
· 不使用常用变量名作为包名以免导致歧义
· 使用单数而不是复数，例如使用encoding而不是使用encodings
· 谨慎使用缩写，例如fmt在不破环上下文的情况下比format更简短
控制流程
· 避免嵌套，保证流程清晰
例如if else语句中两个分支都包含了return，则可以去掉else把else的return语句放在if外面这样就能省去一次判断
· 优先处理错误，尽量避免返回或者继续循环
· 尽量保持正常代码路径为最小缩进
· 处理逻辑尽量走直线，避免复杂的嵌套分支
· 正常流程代码沿着屏幕向下移动
· 提升代码的可维护性和可读性
· 故障大多出在复杂的条件语句或者循环语句中
错误异常处理
· 简单错误(在其他地方不需要捕捉)
优先用errors.New来创建匿名变量来直接表示简单错误；如果有格式化要求可以使用：fmt.Errorf() 返回错误并且在控制台输出，你可以在里面添加任何用于占位的字符，并且可以使用格式化输出，注意用%w来格式化输出你的错误
· 错误的Warp和Unwarp
Warp提供了错误套错误的能力，可以实现一个error跟踪链来追寻到错误的最终原因，用%w关键字来将一个错误关联至错误链中。
· 错误判定
errors.Is()来判断一个错误是否为特定错误。 例如：errors.Is(err1,err2)用于判断err1是否与err2是同类的错误err1是被判断的错误，err2是目标错误
Errors.As(err1,&err)
同样用于判断err1是否和err是同类型的错误，不同在于第二个参数是我们需要判断的错误的指针类型，可以把这个错误取出来，方便去定位分析问题。
Panic
真正异常情况，程序已经无法执行。不在业务代码中使用。当程序在启动阶段出现不可逆的错误时，可以在init或者main函数中使用panic 若问题可以被解决建议用error代替panic
Recover
用于处理panic，程序用recover来捕获异常，程序即使出现了panic仍然可以继续运行defer然后中断后续的执行
defer func() {
if err := recover(); err !=nil {
fmt.Println(err)
}
