-
gRPC反射服务没启用，grpcurl直接报错"failedtoresolvemethod:notfound"根本原因不是工具问题，而是服务端压根没注册反射服务。Go的grpc.Server默认不开启反射，必须手动加一行注册逻辑。实操建议：在启动gRPC服务的main函数里，调用reflection.Register(server)，且必须在server.Serve()之前确保导入了"google.golang.org/grpc/reflection"包，这
-
结构体字段必须首字母大写且用xml:"name"等标签显式声明映射规则，否则解析静默失败；命名空间、空元素、类型匹配、根节点名不一致等均导致零值；动态/大XML应改用Token流式解析。
-
Go函数参数均为值传递，slice、map、chan等“引用类型”实为含指针字段的结构体值；传参拷贝结构体而非底层数据，故append需接收返回值，map/chan内容可直接修改。
-
Delve（dlv）是Go项目最主流可靠的调试工具，支持goroutine、channel等原生特性，可命令行或IDE集成使用；安装用goinstallgithub.com/go-delve/delve/cmd/dlv@latest，验证用dlvversion。
-
应使用一维滚动数组，因二维易内存超限且Go中切片扩容与GC压力大；倒序遍历重量是为避免误用本轮更新值，确保01背包语义正确。
-
最稳方法是用time.Date构造月初月末：月初为当月1日0点，月末为下月1日减1天；必须显式指定time.Location避免时区漂移，且需校验输入time.Time非零值。
-
倒排索引构建核心是map[string][]int，将词映射到其出现的文档ID升序列表；需小写归一化、去标点、空白分词，文档ID用连续整数；AND搜索用双指针归并求交，避免嵌套遍历。
-
为什么不用sync.Once做限流器单例？因为sync.Once只保证初始化一次，不解决并发访问时的计数竞争问题。限流器核心是「判断+更新」原子操作，比如令牌桶扣减或滑动窗口时间片统计——sync.Once完全不参与这个过程，它只帮你new一次对象，后续所有Allow()、Reserve()还得自己加锁或用原子操作。常见错误现象：rate.Limiter实例被多次初始化，或多个协程同时调用TryConsume()导致漏判（本该拒绝的请求放行了）。正确做法：单例封装的是带状态的限
-
GOMEMLIMIT不是硬内存限制，而是通过提前触发GC来软约束堆内存；它不影响mmap、cgo等非堆内存，RSS仍可能超限被OOMKilled。
-
GOGC调太低会因高频GC导致STW累积变长；应结合内存增长节奏、对象生命周期和压测动态调整，优先优化分配模式与对象复用。
-
直接改http.DefaultTransport很危险，因其是全局单例，第三方库可能复用导致请求异常；应新建独立http.Client并自定义Transport，分层配置超时，安全复用连接池与TLS会话。
-
为什么直接用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)和易回溯、编译慢、内存暴涨。
