-
Go中HMAC签名失败主因是密钥与消息顺序错乱、哈希函数不匹配、Header字段名/格式不一致、并发复用非线程安全hasher，需严格对齐服务端要求的密钥编码、时间格式、换行符、算法类型及Header规范。
-
首先定义任务结构体并通过channel传递任务，创建带缓冲的channel存放任务；然后启动多个工作协程从channel中并发读取并执行任务，直至channel关闭，实现高效的任务分发与调度。
-
用docker.Client连本地daemon需显式指定host为unix:///var/run/docker.sock，Linux/macOS注意用户权限，WSL2需开启DockerDesktop的WSLintegration；ImagePull必须消费io.ReadCloser全部内容，否则阻塞；ContainerCreate返回的resp.ID是字符串，需传给ContainerStart；ContainerList默认只返回运行中容器，查全部需设All:true。
-
Asynq启动连不上Redis需检查地址、密码及连接池配置；handlerpanic因类型名不一致或注册时机错误；幂等需任务ID加业务层唯一校验；本地开发推荐DockerRedis而非mock；测试用asynq.TestClient；CI可用miniredis。
-
最直接的网络连通性测试是用net.Dial建立TCP连接，需显式设置context.WithTimeout防卡死，地址格式为"host:port"，返回nil仅表示三次握手成功；HTTP测试应使用带超时的http.Client并检查StatusCode；自定义协议需手动读写并设读写超时；并发压测须自定义Transport避免连接池瓶颈。
-
正确测试HTTP超时需用httptest.NewUnstartedServer并手动注入延迟，配合显式设置Client.Timeout，断言时用errors.Is(err,context.DeadlineExceeded)，并发场景需避免handler串行阻塞。
-
Go程序高并发下CPU缓存命中率低的主因是数据访问模式未适配硬件特性：struct字段顺序影响缓存行对齐，伪共享导致频繁缓存失效，数组比切片更利于预取和向量化，需结合pprof与perf定位真实瓶颈。
-
Go错误处理应统一分类、封装构造与判断、注入上下文、分层处理；用语义化错误类型替代字符串比较，通过%w构建错误链，errors.Join合并多错，中间件/defer外提错误处理，结构化日志注入上下文。
-
协程泄漏可通过监控协程数、使用pprof分析堆栈、优化退出机制来排查和预防。首先，通过runtime.NumGoroutine()监控协程数量，若持续增长则可能存在泄漏；其次，使用pprof查看goroutine堆栈，重点检查处于chanreceive、select或sleep状态的协程；最后，在编码中避免常见问题，如忘记关闭channel、select无default分支、循环中无限启动协程，并结合日志埋点和context控制生命周期，确保协程能正常退出。
-
fsnotify漏事件是因底层inotify/kqueue/ReadDirectoryChangesW缓冲区溢出或atomicwrite导致路径失效；应监听目录而非文件，用filepath.Base过滤，并防抖处理多事件。
-
Go标准库compress包是压缩算法的组织者，不直接提供实现；其子包flate、gzip、zlib、lzw和bzip2分别对应不同格式：flate实现纯DEFLATE流，无头尾；gzip遵循RFC1952，含header与trailer；zlib依RFC1950，常用于PNG与HTTP；lzw用于GIF，需指定字节序；bzip2仅支持解压。
-
json.MarshalIndent是最轻量可控的JSON格式化方式，应避免fmt.Println导致多余换行，推荐用os.Stdout.Write输出、双空格缩进，并需处理输入超时、长度限制、编码异常及跨平台问题。
-
Go的http.FileServer为什么直接托管SPA会404？因为http.FileServer只按路径找真实文件，而SPA的路由（比如/dashboard、/user/profile）根本没对应磁盘文件，一访问就返回404。它不理解前端路由是靠JS在浏览器里“假装跳转”的。常见错误现象：GET/admin→404，但GET/index.html能打开；刷新任意前端路由页面就崩。必须拦截所有非静态资源请求（即不是.js、.css、.png等后缀），统
-
需手动调用reflection.Register(s)注册反射服务，且必须在grpc.Server.Serve()前执行；import"google.golang.org/grpc/reflection"不可省略，生产环境建议关闭。
-
直接在每个函数写iferr!=nil会重复冗长、淹没业务逻辑，且难以统一加日志、重试或转HTTP状态码；defer+panic不可行，因panic不处理普通error、破坏栈、影响性能，且Go官方反对；可行方案是中间件模式+分层错误封装：定义带Code/Message/Status/Err的AppError类型，并在handler入口统一处理，同时用%w保持错误链、避免context.Value传traceID。
