-
系统调用会阻塞M但P不闲置，运行时自动转移P给其他M；netpoller通过事件驱动避免M阻塞；cgo调用不直接阻塞调度器但可能引发P解绑；需用GODEBUG和指标监控M堆积。
-
不能直接close(channel)后退出生产者，因为close是广播“永不写入”信号，若消费者尚未读完，会导致读取已关闭channel时ok=false，产生逻辑错误或提前终止；正确做法是确保所有生产者完成且无新数据后才关闭。
-
性能优化应在真实负载下出现可复现问题时启动，如HTTP延迟>200ms、goroutine超5000持续增长、GC频次>1次/秒或单次暂停>5ms、CPU长期>70%且热点在业务逻辑；gobuild-ldflags="-s-w"仅减小二进制体积，不影响运行时性能。
-
reflect.Convert仅支持底层类型相同或明确定义的表示转换，不支持语义转换（如int64转string、[]byte转json.RawMessage），需分层处理：底层兼容→接口实现→基础类型手动分支→递归反射。
-
Operator是基于CRD和控制器模式实现的有状态应用运维自动化工具，CRD定义自定义资源，Operator实现其管理逻辑；kubebuilder用于初始化项目并生成CRD与控制器骨架，Reconcile函数负责对齐期望与实际状态，本地用makerun调试，需注意RBAC、CRD安装及status更新等细节。
-
Go中无内置迭代器接口，但可用闭包模拟：工厂函数封装索引状态，返回func()(T,bool)实现Next；亦可定义泛型Iterator[T]接口或用channel实现并发安全迭代。
-
根本原因是Linux内核capability缺失，需用setcap授予权限或Docker中--cap-add透传；避免sudo，改用unix包替代已弃用的syscall。
-
t.Log输出仅在测试失败或启用-gotest-v时显示，支持任意类型参数自动格式化，不可在init中调用且不属stdout；t.Logf仅多出格式化语法，二者行为一致。
-
答案是确保依赖一致性、优化缓存机制、合理管理多模块依赖。核心在于提交go.mod/go.sum、统一Go版本、配置GOPROXY；通过go.sum哈希缓存GOMODCACHE提升构建速度；在多模块项目中使用replace指令管理内部依赖，结合语义化版本与GitTag实现自动化发布。
-
reflect.TypeOf和reflect.ValueOf慢是因为每次调用都需解析类型结构、分配对象并遍历元数据树；应缓存structInfo等元数据而非Type/Value本身，优先用sync.Once+包级变量。
-
Counter比Gauge更适合吞吐量，因其记录只增不减的累计请求数，支持速率计算且避免瞬时值干扰；实操需正确初始化、避免重复统计、规范标签、显式配置导出器并优化高并发性能。
-
本文详解如何在Go中正确格式化货币数值，兼顾千位逗号分隔、两位小数精度，并重点强调避免使用float64处理金额，推荐采用dec/inf、big.Float或accounting等高精度方案。
-
Go服务暴露Prometheus指标需用promhttp.Handler()注册/metrics路由，避免手写响应；正确选型Counter/Gauge/Histogram，防重复注册panic，确保HTTP服务启动前完成指标注册与挂载。
-
for{}不会卡死程序但会独占goroutine，导致CPU100%和其它goroutine饿死；应配合time.Sleep、runtime.Gosched()或select避免空转。
-
Go原生支持基准测试，需用BenchmarkXxx函数对比相同逻辑与输入规模的实现，统一初始化、禁用GC和编译器优化，并以ns/op为关键指标评估性能。
