-
为什么直接用sync.Map不适合做业务缓存因为sync.Map是为高并发读多写少场景优化的底层结构，缺乏过期、淘汰、统计等缓存必需能力。它不支持TTL（Time-To-Live），不能自动驱逐旧数据，也没有命中率监控接口——这些在真实服务中几乎必须。用sync.Map手动实现过期逻辑，会引入定时器或懒检查，极易导致内存泄漏或时序错误没有容量限制，缓存无限增长，可能触发GC压力或OOM无法区分“未命中”和“值为nil”，业务层需额外包装，增加出错概率推荐方案：用gi
-
推荐使用T.Log、T.Logf等方法记录测试日志，测试失败或加-v参数时自动输出，便于调试。
-
len()返回字符串字节长度而非Unicode字符数，如"你好"返回6；需用utf8.RuneCountInString()获取真实字符数，截取应转[]rune操作避免UTF-8损坏。
-
应使用AC自动机而非strings.Contains或正则：前者时间复杂度O(n)，支持高效多模匹配；后者分别为O(n×m)和易回溯、编译慢、内存暴涨。
-
字符串拼接时+和+=在循环中很慢，因Go字符串不可变，每次拼接需分配新数组并复制，N次操作时间复杂度达O(N²)；推荐用strings.Builder（预估容量、非并发）、strings.Join（切片拼接）或fmt.Sprintf（少量格式化）。
-
multipart.FormValue无法获取文件字段，因为它只解析非文件类表单值（如text、hidden），跳过type="file"字段；需先调用r.ParseMultipartForm或r.ParseForm，再用r.FormValue取文本、r.FormFile取文件。
-
Go语言中if语句支持多条件组合与嵌套，用于实现复杂分支逻辑。1.使用&&、||、!连接多个条件，如ifx>=0&&x<10判断范围；2.可结合短路求值优化性能，将易为假的条件前置；3.支持if-else和elseif结构处理互斥条件；4.嵌套if适用于层级判断，如登录权限控制，但不宜超过三层；5.常用于输入校验、状态机等场景，需注意表达式清晰性与括号优先级。合理使用可提升代码可读性与可靠性。
-
长轮询本质是服务端延迟响应以保持HTTP连接打开，等待数据或超时后才返回；需用context控制超时、避免裸sleep、及时释放资源。
-
应使用带房间级sync.RWMutex的map[string][]*websocket.Conn管理连接，限制room_id字符集，显式传递房间标识，为每次WriteMessage设置独立writedeadline，并确保HTTP升级握手正确完成。
-
Go程序默认能跑满CPU，所谓“没跑满”通常是因I/O、锁、GC或串行逻辑阻塞goroutine；runtime.GOMAXPROCS默认为逻辑核数，仅在cgroup限核未感知或早期初始化时需干预，错误设置会引发调度开销或资源浪费。
-
context.WithCancel是并发取消的唯一可靠方式，因其通过ctx.Done()返回只读channel实现跨goroutine同步取消通知，避免手写标志导致的响应延迟、竞态和清理遗漏。
-
pprof连不上因默认监听localhost，需显式绑定0.0.0.0:6060并检查网络策略；查全部goroutine必加?debug=2；定位泄漏靠对比快照中createdby行；命令行比WebUI更适合深度分析。
-
应使用go.opentelemetry.io/otel，避免已归档的opentracing-go和go-opencensus；初始化TracerProvider后必须显式调用Shutdown()防止trace丢失；导出器开发用Jaeger（UDP6831），生产用OTLP；务必设置service.name；HTTP自动透传用otelhttp.NewHandler；数据库需用otelsql.RegisterDriver全链路拦截；禁用高基数字段；异步goroutine必须传递上游context。
-
使用Testify时需避免断言错误消息格式化问题，如"%!(EXTRAint=0)"，应升级至新版并用索引占位符"%[1]v"明确参数；推荐使用assert.Equal、assert.ErrorContains等语义化方法提升可读性；团队应统一规范，结合t.Run命名和上下文信息确保错误提示清晰准确。
-
Go语言不支持继承，仅通过嵌入实现组合，嵌入是字段提升与方法代理，非IS-A关系；接口隐式实现配合组合构成多态核心，滥用嵌入会导致语义模糊与耦合加重。
