-
Go无传统构造函数，惯用NewXxx()函数初始化对象；返回指针而非值类型，主要出于方法调用链支持、地址可达性保障（如map元素）、内存效率及语义清晰性等工程考量。
-
集成工作流引擎可解耦业务逻辑与流程控制，提升系统可维护性和可观测性；在Golang中，Temporal因原生支持、强大功能和活跃社区成为首选方案，适用于复杂业务编排，而简单场景可选自研状态机或Conductor。
-
为什么filepath.Walk比os.ReadDir+手动递归慢一倍？因为filepath.Walk默认对每个文件调用os.Stat，哪怕你只关心路径名。它会为每个条目触发一次系统调用，而os.ReadDir（Go1.16+）返回的fs.DirEntry已经包含类型和名称，IsDir()不触发额外stat。优先用os.ReadDir替代filepath.ReadDir（后者已弃用）递归时只对确认是目录的条目再调用os.ReadDir，跳过os.Stat避免
-
盲目增加goroutine数量易引发调度争抢、内存暴涨和OOM；应使用workerpool限流，合理选择channel缓存策略，慎用context超时，正确复用sync.Pool对象。
-
gomodtidy只补全实际import的模块并移除未被直接或间接引用的模块，会误删//go:embed、构建tag或测试文件中的依赖，空导入保留，间接依赖需验证后清理。
-
container/heap不能直接当优先队列用，因它仅提供底层堆操作接口，需手动实现heap.Interface的五个方法（尤其是Less需严格匹配调度语义），否则编译报错。
-
Go的net.Conn.Write()在内核套接字发送缓冲区有足够空间时立即返回（完成系统调用），此时goroutine即被调度器重新激活；若缓冲区不足，则阻塞于runtime的网络轮询器，直至缓冲区腾出空间。时间戳应在Write返回后获取，代表数据已安全进入内核空间。
-
Go测试中无法在TestMain直接加载插件，因构建模式不一致易panic；应改用子进程通信（如HTTP/Unixsocket），插件需单独构建且Go版本严格一致。
-
<p>CQRS在Go中不能简单套用Java/C#模式，需明确读写边界：写操作校验规则并更新状态，读操作避事务锁、允脏读、防缓存穿透；需合理使用事务、事件类型版本化、数据库生成时间戳以保障一致性。</p>
-
Atomic.AddInt64能扛高并发，但仅保证单次加法原子性；“先查后改”不安全，锁开销大，需注意内存对齐、避免自旋读写、必须用Atomic.StoreInt64初始化。
-
Go程序通过client-go调用KubernetesAPI创建NetworkPolicy资源，由CNI插件（如Calico/Cilium）实现策略，而非直接操作iptables或ebpf；需正确设置RBAC、使用scheme获取apiVersion、避免YAML解析错误。
-
CGO调用慢的根本原因是栈切换、写屏障检查和GC暂停等待；C.CString/C.GoString引发深拷贝，高频调用开销达50–200ns；应复用C内存、避免循环分配、慎用deferfree，并优先将计算移至Go侧。
-
直接用httputil.NewSingleHostReverseProxy会丢请求头，因其默认过滤敏感头（如Connection、Host）且替换Host导致路由错误；需重写Director保留原始Host，用ModifyResponse清理chunked，禁用默认header过滤。
-
在Golang中开启RPC压缩需自定义编解码器，具体步骤如下：1.在客户端和服务端分别注册自定义的ClientCodec和ServerCodec；2.使用bufio.Writer配合gzip.NewWriter或flate.NewReader实现数据的压缩与解压；选择压缩算法时，若追求性能且通信双方为Go语言编写，推荐使用更轻量的flate，否则可选gzip；此外，编码优化包括减少结构体字段、拆分大请求、启用连接复用及使用sync.Pool缓存压缩资源，以降低GC压力并提升性能。
-
用map和结构体可快速搭建Go评分模型：movie用map[string]Movie，rating用map[int64][]Rating，配sync.RWMutex；Movie.ID用string、Rating.Score用float32；CalculateAverageScore需判空并用float64累加，结果保留一位小数；HTTP接口须校验JWT用户ID、防重复提交；SQLite需手动启用外键、日期存ISO8601格式。
