-
reflect.New是运行时根据reflect.Type创建结构体指针的首选方法，返回可寻址的*T，需配合Elem()获取结构体值并赋值，字段名须导出且类型严格匹配。
-
答案：Golang微服务异步通信主要通过消息队列（如RabbitMQ）、Kafka、NATS及gRPC结合消息队列实现；RabbitMQ支持可靠消息传递，Kafka适用于高吞吐场景，NATS轻量实时，gRPC结合队列可实现异步解耦，配合Go的goroutine与channel构建高效系统。
-
Go中获取结构体需明确目标：用reflect.TypeOf获取类型对象（推荐(*MyStruct)(nil)).Elem()），遍历导出方法需检查m.PkgPath为空且区分接收者类型，提取参数从In(1)开始并先校验NumIn()>1。
-
net/http默认不处理跨域，因其http.ServeMux和Handler仅负责基础请求响应，不实现CORS规范；需手动添加中间件（如rs/cors）或在API网关层统一配置。
-
Gomap的key必须支持==和!=，因为底层依赖哈希与相等判断定位键；不可比较类型（如slice、map、func）作key会导致编译错误或运行时panic。
-
error是接口而非关键字，需显式检查；必须用iferr!=nil判断，禁用iferr或_忽略；推荐errors.New、fmt.Errorf（%w包装）和谨慎自定义结构体；优先用errors.Is/errors.As判定错误，避免字符串匹配；包装错误应精简，仅入口层加必要上下文。
-
Golang中实现UDP通信无需建立连接，通过ReadFromUDP和WriteToUDP直接收发数据报，服务端可一个连接处理多个客户端，适合低延迟、高并发场景；而TCP需通过Accept建立连接，基于字节流传输，需处理粘包，但保证可靠有序，适合文件传输等场景；因此应根据是否需要可靠性、延迟要求、连接状态管理来选择协议，UDP编程更轻量但需应用层补足可靠性。
-
Go编译本身快，但大型项目感知延迟主因是构建流程瓶颈：golist扫描、模块校验超时、重复go:generate、CGO调用及误用-a/-i等过时参数；优化GOPROXY/GOSUMDB、按需触发generate、禁用-a/-i可解决90%问题。
-
gorilla/websocket需补全连接池、并发写保护、超时控制等机制才能用于分发系统；必须用gorilla/mux路由提取路径参数并绑定会话，用sync.Map存连接且广播前需拷贝切片，消息分发须按私聊/群发/广播分类处理并设写超时。
-
interface{}转换会触发内存分配和类型信息查找，因其底层由类型指针（itab）和数据指针（data）组成，赋值时需运行时写入二者，小对象可能逃逸至堆，循环中频繁使用会导致性能问题。
-
Go语言中死锁常因goroutine在channel操作上相互阻塞且无其他goroutine推进导致，如向无缓冲channel发送数据而无接收者时触发运行时死锁报错。
-
Go反射操作slice需确保可寻址，用reflect.ValueOf(&slice).Elem()获取可修改值；扩容用Append或MakeSlice，设值需通过Index(i).Set()且类型匹配。
-
copy函数仅浅拷贝，对指针、map、slice等引用类型只复制地址；修改新切片的嵌套结构会影响原切片，适用场景限于基本类型或无引用字段的struct。
-
直接用chan无法安全实现多生产者多消费者，因无缓冲chan要求收发同步，多生产者易阻塞；且多个生产者共用通道时自行close会panic（closeofclosedchannel）或致数据丢失，必须由单独goroutine在所有生产者完成wg.Wait()后统一关闭。
-
Go程序高并发下CPU缓存命中率低的主因是数据访问模式未适配硬件特性：struct字段顺序影响缓存行对齐，伪共享导致频繁缓存失效，数组比切片更利于预取和向量化，需结合pprof与perf定位真实瓶颈。
