-
ErrGroup比手动WaitGroup+channel更可靠，因其天然支持错误即取消、共享context、幂等错误处理；而手动实现易导致goroutine泄漏、取消失效、panic丢失等问题。
-
组合模式通过接口统一处理叶子与容器节点，利用Go的接口和结构体嵌套实现树形结构；定义Component接口规范Display、Add、Remove行为，Leaf作为终端对象仅展示自身并拒绝增删操作，Composite维护子节点切片并递归渲染；构建时可灵活组装如文件系统等层级结构，root.Display输出缩进树形，适用于需统一操作个体与整体的场景。
-
使用Golang原生功能实现用户注册与登录，包含路由设计、表单处理、bcrypt密码哈希、SQLite存储及基于Cookie的Session管理，适合学习但生产环境需结合Redis与HTTPS增强安全。
-
敏感词检测不能用strings.Contains硬扫，因其时间复杂度O(N×M)效率低且不支持前缀匹配、模糊变体等业务需求；应使用基于rune构建的Trie树（如github.com/zieckey/gotrie），统一转小写、预处理空格符号，并调用FindLongestPrefix提升准确率与性能。
-
答案是使用strings.Contains函数可判断字符串是否包含子串，该函数区分大小写并返回布尔值。示例：strings.Contains("Hello","He")返回true；空子串始终返回true；忽略大小写时可用strings.ToLower转换后再比较，适合日常高效匹配。
-
Go标准库json包已足够通用，reflect仅被其内部用于字段遍历和值读写，不可也不应替代json.Marshal/Unmarshal；因reflect缺乏标签解析、omitempty语义、自定义方法调用、循环引用处理等编解码必需能力。
-
counter++必然竞态，因其拆为读-加-写三步，多goroutine可能同时读旧值导致更新丢失；应全程使用atomic.AddInt64等原子操作，且变量须为int64、取地址调用、所有读写均走atomic函数。
-
sync.Pool为什么不能直接存指针到结构体？因为sync.Pool不保证对象生命周期，Put进去的值可能被随时GC回收或清空，如果存的是指向堆上结构体的指针，而该结构体本身没被Pool管理，就容易出现悬垂指针或重复初始化问题。常见错误现象：panic:runtimeerror:invalidmemoryaddress或字段值“随机”变零——其实是拿了已被复用/重置的对象。正确做法：Pool存的是值类型（如*MyStruct），且每次Get()后必须检查是否为
-
interface{}与nil直接比较常失效，因其是含类型和数据的两字宽结构体；即使底层值为nil，只要类型信息非空，接口值就不等于nil。
-
Go中可用高阶函数模拟装饰器，需保持原函数签名一致，用time.Since()安全计时，defer中recover确保panic时仍输出耗时，日志应并发安全且与业务分离。
-
Stackwalking是GC在标记阶段扫描goroutine栈以识别存活指针的过程；它依赖编译器生成的funcinfo和pcdata元数据，逐帧解析栈内容，精准判定哪些值是指针并加入标记队列，确保逃逸分析未覆盖的引用（如栈变量地址写入堆、接口/切片header等）不被误回收。
-
从一次下游接口卡死导致 goroutine 和连接堆积的事故出发，讲清 Go http.Client Timeout、Transport 超时、Request Context、连接复用、重试边界和上线检查。
-
Go 服务出现 goroutine 数持续上涨、接口超时或后台任务堆积时，channel 发送阻塞是常见原因之一。排查时先看 goroutine profile 里的 chan send，再确认接收方是否退出、消费是否变慢、缓冲是否打满，并用超时退出或限流恢复服务。
-
Operator核心是理解Kubernetes控制循环：监听资源、比对期望与实际状态、调用API修正；Go只是工具，关键在幂等、非阻塞、使用controller-runtime的Reconcile函数，并正确处理CRD、OwnerReference、Finalizer及调试日志。
-
zap.Logger日志级别由core决定且不可变，动态调级需用zap.AtomicLevel配合自建core；WithOptions等方法仅影响初始化，不改变已创建Logger的级别。
