-
Go 的流式响应不是把多次 Write 拼起来就结束了。本文从 http.ResponseController.Flush 入手，做一个可验证的 SSE 示例，解释缓冲何时真正送达、HTTP/2 与代理会带来什么差异，以及客户端断开后如何让 goroutine 和 ticker 及时收口。
-
应使用interface{}定义策略当算法差异大、生命周期独立且不共享状态时，如支付方式；避免将共用字段强塞入接口，宜用组合或工厂；策略应无条件判断，条件选择前置；函数类型无法携带状态和依赖，不利测试与维护；DI与插件策略可分层处理。
-
默认的gin.Recovery()只捕获主goroutine的panic，异步goroutine中的panic需手动recover；c.Error()不中断执行，c.AbortWithError()才终止后续handler并写入响应。
-
策略接口应定义具体窄接口而非interface{}，以保留编译期类型检查；推荐用注册表+工厂函数解耦策略选择，输入输出需统一封装校验，避免panic和全局依赖。
-
直接用goroutine无法实现真正任务隔离，因其共享进程内存、全局状态和运行时环境，易导致日志污染、HTTP超时篡改、随机数序列破坏或panic崩溃整个服务；必须通过独立进程（如exec.CommandContext）实现系统调用、运行时及可观测行为三重隔离。
-
Go用嵌入而非继承实现组合模式，因无传统继承机制，需靠接口抽象+值聚合；节点统一实现TreeNode接口，Composite用[]TreeNode聚合子节点，Leaf返回空切片，避免nil导致遍历错误。
-
RWMutex在读占比≥70%且临界区极轻时吞吐达Mutex的2–5倍；读≤40%时Mutex更稳更快；40%–60%区间性能持平但RWMutex死锁风险陡增；写超30%时RWMutex吞吐反低20%–40%，根本瓶颈在于锁粒度与临界区设计。
-
ssh.ClientConn不能直接执行命令，必须通过ssh.Client：ssh.Dial→ssh.Client→client.NewSession()→session.Run()；认证失败多因密钥格式（不支持OpenSSH格式）或签名算法（如rsa-sha1被禁用）不匹配；密码认证需用ssh.Password类型；session.Run()必须检查返回err，非零退出码需用*ssh.ExitError断言获取；交互命令需RequestPty并显式设置Stderr和Signal。
-
Go服务指标无法被Grafana展示的根本原因是Prometheus未成功抓取数据，需依次检查/metrics接口注册与可达性、打点逻辑正确性、Prometheustargets状态及直方图查询语法。
-
跳表在并发读多写少场景下优于sync.RWMutex+切片二分，因写操作平均O(logn)且可细粒度锁/CAS，读完全无锁；而后者写需O(n)内存搬移和排他锁，高并发写吞吐骤降。
-
math.Inf(1)和math.Inf(-1)怎么用才不会误判Go的math.Inf(1)生成正无穷，math.Inf(-1)是负无穷，但它们不是常量，不能直接写在const声明里；更关键的是，==对无穷值的比较是合法的，但容易和浮点精度问题混淆。别用a==math.Inf(1)判定无穷——虽然语法对，但若a来自计算（比如除零），某些编译器或平台可能因优化导致行为不一致；应改用math.IsInf(a,1)math.IsInf(x,0)可同时匹配正负无穷；
-
使用官方registry镜像可快速搭建本地Golang镜像仓库，通过dockerrun启动服务并配置持久化存储；构建Golang项目镜像后需重新tag为localhost:5000/命名格式再推送；其他机器拉取前须在daemon.json中配置insecure-registries以支持HTTP访问；定期执行垃圾回收和备份registry-data目录确保存储可控与数据安全。
-
Go使用-buildmode=c-shared编译共享库时，导出函数不能直接接收Go原生string类型；必须使用*C.char并通过C.GoString()转换，否则会因内存布局不匹配触发runtimeout-of-memorypanic。Go使用`-buildmode=c-shared`编译共享库时，导出函数不能直接接收Go原生`string`类型；必须使用`*C.char`并通过`C.GoString(
-
Go层自实现流量镜像需绕过req.Body只能读一次的限制，通过io.ReadAll一次性读取后分发，并用req.Clone隔离修改，设置超时client静默处理失败，且必须受配置开关控制。
-
recover()只能在同Goroutine的defer中捕获本Goroutine的panic，因各Goroutine调用栈独立；需在出问题的Goroutine内用deferrecover()，或用errgroup.Group、带缓冲channel统一处理错误。
