-
根本原因是program路径未指向已编译的可执行文件；必须用gobuild生成二进制，program设为对应路径（Windows需含.exe），并配合cwd、envFile等正确配置。
-
Go模块管理不负责依赖注入，DI需额外工具如Wire实现；Wire在编译期生成无反射的初始化代码，避免运行时错误与IDE功能退化，但Provider签名变更会导致构建失败且不受go.mod版本约束保护。
-
defer在return语句确定返回值后、函数栈销毁前执行；命名返回值可被defer修改，非命名则不可；多个defer按注册顺序后进先出执行；参数在defer语句出现时即求值；需谨慎用于资源清理与panic恢复，注意性能开销。
-
该用指针接收器而非值接收器的情况包括：方法需修改receiver状态、receiver含不可拷贝字段（如sync.Mutex）、结构体较大（≥16字节）或含slice/map/chan/func/interface字段；值接收器仅适用于纯只读小结构体。
-
直接用channel+map实现Pub/Sub易崩，因channel不支持广播、易死锁或漏事件，且subscriber崩溃后publisher仍发数据导致panic；应引入dispatchergoroutine和sync.Map管理订阅，用泛型约束payload类型防类型擦除。
-
百度翻译API签名需用UTF-8原始字节拼接q+app_id+salt+secret_key后MD5；有道API的curtime须为秒级时间戳且参与sign计算；q/input均不可URL编码，HTTP客户端须设超时与重试。
-
http.ServeMux高并发时变慢因线性遍历O(n)匹配、无Trie优化、不区分动静态段；gorilla/mux需StrictSlash和预编译正则才提效；自研Trie可两级哈希降开销；原生优化重在减少字符串拷贝与内存分配。
-
滑动窗口限流不能仅用RedisINCR+EXPIRE，因二者非原子操作，易导致key永久存在或丢失、窗口错乱；必须用Lua脚本保证计数与过期设置的原子性，并统一使用Redis服务端时间戳。
-
goroutine泄露的典型表现是程序内存持续上涨、runtime.NumGoroutine()返回值只增不减、pprof查看/debug/pprof/goroutine?debug=2里堆栈长期卡在channelreceive、time.Sleep或sync.WaitGroup.Wait；常见诱因包括忘记关闭channel、select没写default或case。
-
最稳方案是预分配索引数组+sync.WaitGroup：初始化results[i]切片，每个goroutine按原始索引i写入results[i]，WaitGroup等待全部完成，避免channel排序或map竞争。
-
灰度发布应在http.Handler中间件实现，通过只读配置与线程安全匹配函数在请求入口按header→cookie→query→IP优先级分流，避免全局变量、远程调用和正则重复编译，利用context透传结果，支持配置热更新与完备测试。
-
Go的netpoller并非简单封装epoll，而是将epoll与goroutine调度深度耦合：Read/Write等同步接口自动触发gopark/goready，实现阻塞式写法、非阻塞式执行。
-
Go禁止import循环，编译期即报错；解法是提取公共接口到独立包或改用回调注入，replace和构建标签均无效。
-
<p>ch<-v阻塞仅取决于channel状态和缓冲区：无缓冲时必阻塞至接收方同步执行<-ch；有缓冲时仅当len==cap才阻塞。</p>
-
Go用泛型实现Result[T]可类型安全封装成功值与错误，避免interface{}的类型断言风险和错误忽略问题，核心在于通过泛型约束、构造函数封装及IsOk/Unwrap等方法强制显式错误处理。
