-
log.Printf无法支撑微服务链路追踪，因其缺乏全局唯一且透传的trace_id，导致跨服务请求日志上下文丢失；需结合context.Context与zap自动注入trace_id，并统一用OpenTelemetrypropagator处理HTTP/gRPC协议透传，采样应基于trace_id哈希而非随机。
-
备忘录模式不适合作为通用配置管理方案，仅适用于需“可编辑+可撤销”交互的场景（如YAML编辑器），因其仅支持单对象状态快照，缺乏版本、元数据、diff、跨进程共享及生效通知等配置管理必需能力。
-
使用reflect.Value可动态调用函数，如add(3,4)通过Call传参返回7；2.支持多返回值函数，如divide(10,2)返回结果5和nil错误；3.可调用结构体方法，如Calculator的Multiply(6,7)得42；4.注意参数类型、函数签名匹配及私有成员不可访问，Call性能较低应慎用。
-
Go中判断变量是否为零值应优先用reflect.Value.IsZero()，它安全支持所有类型并正确识别nil指针、接口等；但需避免直接传nil接口，结构体字段检查限于导出字段，且推荐类型特化比较替代反射。
-
channel必须初始化才能使用：声明chanint类型变量未用make初始化，运行时panic报「sendonnilchannel」；Go禁止对nilchannel发送或接收数据。
-
Go程序中goroutine泄漏不是“会不会发生”的问题，而是“什么时候被发现”的问题——它往往在压测后内存缓慢上涨、服务重启前卡顿、pprof里看到几百个chanreceive状态协程时才浮出水面。用runtime.NumGoroutine()快速验证测试是否泄漏这是最轻量、最直接的单元测试级检测手段，适合在CI或本地开发阶段快速拦截明显泄漏。它返回当前存活的goroutine总数（含runtime自身维护的，但波动通常很小）关键不是绝对值，而是「操作前后是否回归基线」：启
-
Go连MongoDB需显式设置context超时和ClientOptions，用mongo.Connect()配context.WithTimeout及Ping验证；filter须用bson.M而非JSON字符串；InsertOne后取res.InsertedID；并发操作要用独立子context。
-
Go单例应使用sync.Once+包级指针变量实现，兼顾线程安全、延迟初始化和错误处理；禁用全局变量直接赋值、init()初始化及导出实例变量，确保正确错误传播。
-
gomodtidy是Go官方推荐的唯一可靠自动清理未使用依赖方式，基于go.mod与源码import的双向比对同步增删依赖，但空白导入、条件编译、运行时加载及手动require等情况会导致“该删没删”，需配合验证与参数优化。
-
First查不到记录时返回gorm.ErrRecordNotFound错误而非nil，需用errors.Is(err,gorm.ErrRecordNotFound)显式判断；传参必须为单结构体地址，且应配合Order明确排序意图。
-
不是必须，但绝大多数真实场景下必须用TestMain；它是唯一能串行控制测试生命周期、安全启停外部依赖（如DB、HTTP服务）并避免测试污染的入口，需严格遵循签名和清理规范。
-
excelize读写Excel最稳但易踩坑：Save()需改WriteTo或SaveAs确保落盘；SetCellValue数字需设NumFmt样式防误解析；读取优先用GetCellFloat/Int；并发写须避免共用File实例。
-
atomic.AddInt64是并发计数的默认选择，因counter++非原子而atomic.AddInt64编译为单条CPU原子指令；必须用int64、变量地址稳定、所有读写都走atomic函数。
-
Gopprof可直接定位CPU、内存、goroutine瓶颈，需启用/debug/pprof/端点；CPU采样建议≥30秒，内存profile要区分allocs（总分配）与heap（存活对象），火焰图中mallocgc高占比需溯源调用方。
-
模板消息发送失败需同时满足三条件：服务号已认证、用户已关注、模板ID后台审核启用；silenceper/wechat/v2初始化时Cache不可为nil，须传memory或redis实例；字段key须严格匹配后台定义。
