-
可以，但需满足依赖已缓存、go.mod/go.sum完整未篡改；首次构建后，不执行goget或修改版本即可离线build；通过gomodverify、gomoddownload-json等验证缓存完整性。
-
锁竞争导致goroutine频繁阻塞和调度开销，拉高延迟、降低吞吐；应通过trace定位竞争、细化锁粒度、慎用RWMutex并避免defer误用。
-
HeapAlloc持续上涨且GC后不回落才是内存泄漏真问题；需高频采样runtime.ReadMemStats抓趋势，结合pprof差分分析inuse_objects增长，并排查日志阻塞、cgo卡住、net.Conn未关闭等非代码泄漏源。
-
Golang通过goroutine、channel和sync.WaitGroup实现高效并发，结合context.Context管理超时与取消，在文件读写和网络请求中确保性能与数据一致性。
-
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解析错误。
