-
Go无真正全局错误处理，需统一构造可追踪error、显式传播、分层响应；recover仅捕获同goroutinepanic，不处理普通error；业务错误应返回error而非panic，goroutine错误须显式收集。
-
用Golang构建Excel导出服务应选用excelize/v2库，通过新建工作簿、写入表头与数据、设置格式、删除默认Sheet，最后WriteToResponse直接响应；需注意大文件分批处理、中文编码、日期转换、数值类型及安全校验。
-
select会阻塞，除非有case立刻就绪；它挂起goroutine直到至少一个channel操作可立即完成，无default时全阻塞，nilchannel永不就绪，多case同时就绪则随机执行。
-
Go算法优化核心是选对数据结构并避免排序瓶颈：小数据量用切片优于map，切片优先于链表，排序用sort包而非手写，大数据量优先考虑Top-K等替代方案。
-
通过包装http.ResponseWriter实现方法重写，可在响应头写入前捕获状态码，从而统一注入自定义错误页面或逻辑，适用于所有4xx/5xx错误，而不仅限于404。通过包装`http.ResponseWriter`实现方法重写，可在响应头写入前捕获状态码，从而统一注入自定义错误页面或逻辑，适用于所有4xx/5xx错误，而不仅限于404。在Go的net/http标准库中，ResponseWriter是一个接口，而非具体类型
-
goroutine泄漏、HTTP客户端未复用、错误处理不落地是并发爬虫三大核心问题：需用信号量或缓冲channel限并发，全局复用并配置http.Client，区分错误类型实现精准重试。
-
选kafka-go更适合新手：API直白，dialLeader和NewReader两步即可跑通；sarama功能全但配置复杂，易因超时/重试未设导致静默失败。
-
gRPC微服务不能用retryablehttp做重试，因其仅支持HTTP/1.1，而gRPC基于HTTP/2，存在状态码映射、流控、元数据透传等根本性不兼容，硬套会导致重试失效或panic。
-
time.Now()返回本地时区时间，非UTC或固定时区；格式化须用“2006-01-0215:04:05”模板；解析需检查err；高并发下调用性能无虞，但避免频繁Format。
-
直接用golang.org/x/time/rate配合Gin或http.Handler即可实现高性能限流中间件，无需第三方库；它无锁、内存开销小、精度高，每秒处理数万请求无压力。
-
Go单元测试中需用defer+recover捕获panic，不可用try/catch；推荐返回error而非panic；并发中goroutine的panic无法被主goroutinerecover。
-
Kubernetes通过DNS和Service实现Golang服务的服务发现与负载均衡，Golang应用使用服务名即可访问其他服务，无需额外框架；Service基于标签选择器将流量分发至健康Pod，默认轮询策略，配合readinessProbe确保实例可用；建议配置HTTP客户端连接池与重试机制提升稳定性；对于特殊场景如长连接，可使用HeadlessService获取Pod直连IP并自定义负载均衡。
-
gotest-cover输出的仅为语句执行粗略百分比，无法定位未覆盖行或分支；可靠覆盖率分析需用-coverprofile生成profile文件并配合gotoolcover查看HTML报告。
-
在Go语言中处理网络请求需显式检查错误，首先判断http.Get是否返回err并检查resp.StatusCode≥400；其次设置Client超时避免阻塞，通过自定义Timeout和Transport实现；再通过errors.Is或类型断言区分timeout、连接拒绝等错误类型；最后读取响应体时用io.ReadAll并检查err，确保每一步错误都被捕获处理。
-
Go中指针本身不提供并发安全，真正保障安全的是sync包中的同步机制；指针仅用于共享数据结构地址，需配合Mutex、RWMutex或Atomic等正确同步访问。
