-
应锚定绝对时间点而非循环休眠；启动时记录截止时间，每次用time.Until重新计算剩余时长，避免sleep累积误差。
-
panic退出码固定为2，无法修改；自定义退出码必须用os.Exit；recover仅拦截panic传播，需配合os.Exit实现带码退出。
-
sql.Open()仅初始化数据库句柄，不建立实际连接，因此即使数据库不可用也返回nil错误；需调用db.Ping()主动探测连接有效性。
-
errors.Join是Go1.20+唯一推荐的多重错误组合方式，它构造可展开、可检查、可嵌套的错误集合，支持errors.Is/As递归匹配，自动忽略nil子错误，且不丢失原始类型信息。
-
Go无内置错误日志系统，需手动组合或借助库实现上下文、堆栈、时间、级别记录与落盘；标准log包需配合fmt.Errorf(%w)包装、log.SetFlags设置、os.OpenFile持久化；生产推荐zap结构化日志。
-
调用reflect.Value.Interface()前必须确保值可寻址，否则panic；常见于字面量、map直接取值等场景，正确做法是传指针后Elem()；JSON解析需传指针，marshal仅处理导出字段及jsontag；XML需显式tag处理属性、命名空间和嵌套；反射遍历struct时须先判Kind再Elem()。
-
优先选原生gRPC而非go-micro：gRPC性能高、跨语言强、控制透明，go-microv4虽基于gRPC但抽象过重易调试困难；新项目应从.proto定义、手写Server/Client起步，结合Consul等真实注册中心与自定义resolver实现服务发现。
-
runtime.GC()是什么，什么时候该调用runtime.GC()是Go运行时提供的一个同步强制垃圾回收函数。它会阻塞当前goroutine，直到一轮完整的GC周期完成（包括标记、清扫等阶段）。它不是“建议GC”，而是“立刻执行一次完整GC”。真实场景中极少需要手动调用：-服务启动后预热阶段，想清掉初始化产生的临时对象？通常没必要，Go的GC已足够智能-内存敏感的批处理任务（如图像批量处理）结束后，想立刻释放大块内存？这是较合理的使用场景-在pprof测试前后强
-
gRPC中间件通过拦截器实现通用逻辑复用，Go语言中使用Unary和StreamInterceptor分别处理一元和流式RPC；可通过grpc.UnaryInterceptor注册日志、认证等中间件，结合go-grpc-middleware库链式组合多个拦截器，提升可维护性；认证中间件可校验metadata中的token，流式拦截器则封装ServerStream实现日志记录等功能，增强服务可观测性与安全性。
-
应通过接口抽象、DTO隔离、纯数据事件和配置注入实现微服务解耦：定义独立契约接口，用专属下划线命名DTO转换domain，事件payload仅含可序列化字段并带版本号，配置启动时注入且不可变。
-
gomoddownload卡住的根本原因是默认代理proxy.golang.org国内连接不稳定，需设GOPROXY=https://goproxy.cn,direct并确保环境变量生效，避免DNS干扰和fallback失败。
-
reflect.TypeOf和reflect.ValueOf慢是因为每次调用都需解析类型结构、分配对象并遍历元数据树；应缓存structInfo等元数据而非Type/Value本身，优先用sync.Once+包级变量。
-
Go序列化性能测试须用testing.Benchmark并多次运行取统计量，避免GC和调度干扰；需重置数据、报告内存分配、预热；JSON注意omitempty限制及优化选项；Protobuf推荐gogoproto扩展；MsgPack选型需关注nil处理差异。
-
关键在于必须显式透传context.Context到每个阻塞调用点，因为错误包装不传递超时、取消等运行时状态；忽略ctx会导致上下文生命周期截断，超时逻辑失效。
-
Protobufmap字段在Go中生成*LabelsEntry切片而非map[string]int32，需用GetLabels()安全访问、MutableLabels()写入；JSON序列化键名大小写与顺序不可控，嵌套any需显式UnmarshalTo，key仅支持string/整数。
