-
本文详解如何在Go中通过手动管理smtp.Client实现单连接复用，避免每次发信都重建连接，显著提升高并发邮件发送场景下的性能与资源利用率。
-
UDP客户端用net.DialUDP复用连接收发，需解析目标地址、设读超时、处理无响应；服务端用net.ListenUDP监听，每包启goroutine并发处理；跨机丢包主因防火墙或绑定127.0.0.1；需按最大包长分配缓冲区并自行定义消息边界。
-
perfrecord采集缓存性能必须同时指定-ecycles,instructions,cache-references,cache-misses，因单个事件无法计算命中率，且cache-references表示总访问尝试数而非命中数，需与cache-misses配合推导命中率。
-
用os.Stat判断文件是否存在时，必须用errors.Is(err,os.ErrNotExist)而非err!=nil；存在且无错时才可调用fi.Mode()，其返回值需用Perm()提取纯权限位，并注意跨平台差异与父目录权限影响。
-
Go二进制体积突增主因是间接依赖引入未使用包，尤其含cgo或静态资源的模块；-ldflags'-s-w'可显著瘦身，替换encoding/json为sonic/go-json并验证内联效果更有效。
-
pprof服务没起来？检查net/http/pprof是否已注册Go程序默认不暴露pprof接口，必须手动注册。常见错误是只导入了net/http/pprof却没调用任何初始化逻辑，结果访问/debug/pprof/返回404。正确做法是确保HTTP路由中已挂载pprofhandler：若使用默认mux：只需import_"net/http/pprof"（下划线导入触发init），且程序启动了http.ListenAndServe若用自定义mux（如
-
Go标准库随Go安装包自带，无需单独安装；只需验证Go环境（goversion、goenvGOROOT/GOPATH）、编译运行含标准包的程序，并确保GOROOT指向正确的源码目录$GOROOT/src。
-
jwt-gov4+禁用none等不安全算法且Parse不校验签名，须用ParseWithClaims配合密钥回调和StandardClaims嵌入，并区分错误类型返回对应状态码。
-
推荐使用filepath.WalkDir而非filepath.Walk：性能更高（避免重复os.Stat）、控制更强（支持filepath.SkipDir）、更安全（可主动处理权限错误、软链接环路、递归深度）；匹配逻辑应解耦为可组合的Matcher函数，路径判断优先用strings.HasSuffix；结果需后排序，不依赖遍历顺序。
-
Go错误处理需在首次出错处用errors.WithStack加栈，后续用%w包装；HTTP请求注入traceID到error中；用slog.Any("error",err)统一日志格式；对高频panic如"contextcanceled"做白名单过滤和限流。
-
Go字符串底层是UTF-8编码的只读字节序列，len(s)返回字节数而非字符数；中文占3字节、emoji如“?”占4字节；遍历应使用range获取rune，避免用索引截取或手动拼接非法UTF-8。
-
strconv.Atoi返回error时需用iferr!=nil检查并处理，不可忽略；可类型断言*strconv.NumError获取详情，用errors.Is(err,strconv.ErrRange)等标准方式判断错误类型；推荐封装SafeAtoi函数提供默认值，或改用更灵活的strconv.ParseInt。
-
goroutine中的panic必须在内部用recover捕获，因为panic不跨协程传播，子协程panic后静默退出，主协程不受影响但可能导致数据丢失、资源泄漏、任务中断且无日志；recover仅在本协程defer中有效，需配合debug.Stack()结构化记录并及时退出，不可继续执行业务逻辑。
-
Go的error接口判断几乎零开销，真正性能瓶颈在于错误构造时的堆分配；应复用预定义错误变量、避免循环内fmt.Errorf、慎用panic替代错误返回。
-
HTTP状态码需精准语义化：400表请求解析失败（如JSON格式错），422表业务校验失败（如邮箱已存在）；避免冗余code字段，确保状态码与响应头一致；重定向仅用于浏览器跳转场景，RESTfulAPI禁用3xx。
