-
应统一用len(s)==0判断切片是否为空，而非s==nil；因nil切片和空切片len均为0且len()调用安全，而s==nil仅适用于具体切片类型、在interface{}或泛型中会编译失败，且JSON序列化语义不同。
-
swaginit报错主因是缺失或格式错误的//@title等注释，必须位于main包文件中且连续无空行；类型需显式import、结构体及字段均须首字母大写并带jsontag；docs目录须与二进制同级；CI中需指定-g入口文件路径。
-
用chanstruct{}可实现固定容量信号量：make(chanstruct{},N)创建容量为N的通道，发送操作占用槽位、接收操作释放槽位，从而控制最多N个goroutine并发执行。
-
必须由发送方关闭且仅一次；接收方关、多发送方竞相关、defer无条件关均易panic；forrangech退出需channel已关且缓冲数据读完，缺一不可。
-
最直接记录单个goroutine执行时长是入口time.Now()+defer调用time.Since()，需在goroutine内部获取start时间、避免共享，defer中避免高开销操作；配合context.WithTimeout()主动中断超时任务，定期监控runtime.NumGoroutine()防泄漏，用CPUprofile定位阻塞点。
-
fmt.Printf是唯一真正支持格式化输出的函数，因fmt.Print和fmt.Println不解析%动词，无法控制分隔符、宽度、换行及对齐，而fmt.Printf可精准构造结构化输出、补零格式（如%02d）、结构体调试（%+v/%#v），且在高频场景需配合strings.Builder优化性能。
-
Go1.14+默认不使用vendor/目录，即使存在也会联网拉取模块；必须显式加-mod=vendor参数才能强制从vendor/加载，且需确保GO111MODULE=on、有有效go.mod、已运行gomodtidy、GOPROXY=off、GOSUMDB=off及go.sum完整。
-
围绕 Go 1.24 go.mod 的 tool 指令，讲清如何替代 tools.go、固定工具版本、使用 go get -tool/go tool、接入 CI 和团队落地边界。
-
os.ReadFile在HTTPhandler中直接调用必然拖垮并发，因其底层为同步read(2)系统调用，阻塞OS线程；Go调度器仅能腾挪其他goroutine，但M线程数有限，高并发时大量goroutine堆积在syscall.Read状态，导致CPU利用率低、延迟飙升。
-
Go中WebSocket心跳需服务端启用PingHandler并每25秒发ping、客户端每30秒发JSON心跳包，双方均需超时检测（服务端45秒、客户端60秒）并主动断连，同时注意Nginx超时配置与WriteMessage并发安全。
-
Gorpc.Client默认不复用连接，需手动长期持有同一实例并发调用，并在连接异常时重建；HTTP模式下须自定义http.Transport启用连接池，且需主动健康检查与错误重试。
-
Golang的并发原语主要有channel和mutex。Channel推荐用于goroutine间通信与同步，适用任务协作、信号通知、资源池控制等场景，但需避免滥用无缓冲channel、多写入者及性能敏感场合。Mutex适用于保护共享资源，如变量保护与临界区控制，sync.Mutex与sync.RWMutex分别适合一般与读多写少场景，但要注意死锁、锁粒度及传递问题。选择时应根据是否需要数据传递、执行顺序同步、数据复杂度判断，channel适合流程控制，mutex适合状态保护，两者互补结合使用效果更佳。
-
pprof不直接指出泄漏代码行，需通过三次关键操作定位：采样时加?gc=1触发GC确保快照纯净；选对heap类型（非allocs）；用list和peek深入调用栈至具体分配行，尤其注意goroutine泄漏间接导致堆内存滞留。
-
viper.WatchConfig()仅监听文件变更并触发回调，不自动重读、解析或更新配置；必须在回调中手动调用ReadInConfig()和Unmarshal()，并用atomic.Value原子替换结构体指针，否则viper.Get()和业务变量始终为旧值。
-
工作池是解决goroutine失控的节流阀：固定worker数、带缓冲channel、显式生命周期管理三者缺一不可；缓冲区大小需权衡背压与积压，sync.WaitGroup必须指针传递且Add在go前调用，关闭jobs后需wg.Wait再closeresults。
