-
Go的json.Unmarshal不会panic，非法JSON返回json.SyntaxError（含Offset定位），类型错误实为json.UnmarshalTypeError；需用errors.As捕获，避免字符串匹配，注意嵌套字段错误路径缺失、重复解析性能问题及部分解析导致的隐蔽错误。
-
原型模式通过已有对象创建新对象，在Go中利用结构体复制和接口实现。值复制为浅拷贝，含指针字段时需深拷贝避免数据共享。可通过定义Cloner接口统一克隆行为，复杂结构推荐手动实现Clone方法并递归处理嵌套对象；对于多层嵌套或动态结构，可使用gob序列化实现通用深拷贝，但性能较低，高频场景应手写优化。选择策略：简单结构直接赋值，关键业务手动克隆，临时需求用gob。
-
要显示allocs/op，必须同时使用-benchmem参数和在基准函数中调用b.ReportAllocs()；allocs/op比B/op更关键，因其反映堆分配次数与GC压力。
-
Go的reflect包不支持直接将string类型的reflect.Value转换为int，因为Go类型系统禁止跨类别（如字符串→数字）的底层类型转换；必须借助strconv等标准库进行语义解析。
-
绝大多数业务写操作必须用db.Transaction而非手写Begin/Commit，因db.Begin()返回新事务实例tx，混用db会绕过事务直连数据库；tx提交或回滚后不可复用；db.Transaction仅捕获panic并回滚，不校验逻辑错误、不自动提交，易静默失败；嵌套事务实为SAVEPOINT；HTTP/缓存等I/O操作严禁入事务体，应移至tx.AfterCommit()或异步处理。
-
gRPC客户端默认不支持轮询或随机负载均衡，需显式启用round_robin或自定义balancer；必须通过dns:///resolver获取多地址，且Go1.21+需配置ServiceConfig。
-
GMP是动态协作契约，G在M上运行，M需持有P才能执行用户代码；runtime.GOMAXPROCS控制P数量而非线程数，设过高会导致调度开销增大、竞争加剧、GC变慢。
-
Go官方标准库不提供semaphore类型，应使用golang.org/x/sync/semaphore；Acquire阻塞等待许可，TryAcquire立即返回；必须严格配对申请与释放，且由同一goroutine执行；适用于I/O密集型资源限流，非任务调度。
-
服务端必须用net.ListenUDP，客户端可用DialUDP（适合固定点对点）或ListenUDP(nil)（适合单次上报）；ReadFromUDP/WriteToUDP不可替换为Read/Write，因UDP无连接状态且需显式处理地址、缓冲区、超时及跨平台端口复用等问题。
-
在Go中，当需根据消费者状态动态停止生产者循环时，应使用select语句监听退出通道，而非default分支——这可避免因发送阻塞导致的死锁，是并发安全、符合Go惯用法的标准实践。
-
Go语言中多重返回值常用于返回结果和错误，error应作为最后一个返回值，如funcdivide(a,bfloat64)(float64,error)；建议用结构体实现error接口以增强上下文，函数签名应清晰表达意图，避免多个同类型返回值，使用接口提升可扩展性，长时间操作需接收context.Context以支持取消。
-
答案：在Golang中实现RPC负载均衡需结合服务注册发现与负载策略。通过etcd等注册中心维护节点列表，客户端集成轮询、随机等算法选择节点，并复用连接、设置超时、重试及健康检查机制提升稳定性，最终构建高效可靠的分布式RPC系统。
-
最稳妥方式是用结构体+json标签精准映射，而非map[string]interface{}；字段名不匹配时须用json:"key"显式指定；动态key用map[string]json.RawMessage分步解析；静默失败主因是字段未导出或类型不匹配。
-
Go中无独立“指针数组”类型，常用[]T实现动态指针集合；指向数组的指针[N]T仅用于特殊场景如CGO；需注意对象生命周期、避免悬空指针及合理权衡性能。
-
Go中的chan数据管道是基于channel的惯用模式，本质为串联的单向channel链，强调单向性与关闭传播；普通channel为双向且生命周期模糊。
