-
Go里&&真会短路，但别靠它写副作用逻辑Go的&&确实短路：左边为false时，右边表达式根本不会执行。这是语言规范保证的行为，不是优化技巧，而是语义本身。常见错误是把err!=nil&&handleError(err)这类写法当“安全兜底”，结果handleError带状态修改（比如记录日志、发告警），一旦左边为false，这些操作就静默丢失——因为压根没调用。只在右边是纯判断（如ptr!=nil&&ptr.field>0）或无副作用函数（如isValid(x)&&isI
-
Go应用应只向os.Stdout输出单行JSON日志，由Promtail或FluentBit采集，而非直连Loki；需统一字段命名、禁用换行、正确配置解析与标签映射，避免权限和静默丢弃问题。
-
v是副本而非引用，修改v不影响原切片；改原切片须用索引s[i]；结构体切片中v.Field=x无效；map遍历顺序随机，需显式排序key；并发读写map会panic；string遍历中i是字节偏移而非字符序号。
-
Gochannel的行为由hchan结构体的五个核心字段决定：buf、dataqsiz、sendx、recvx、qcount；它们共同实现逻辑环形缓冲区，其中qcount精确反映元素个数，sendx/recvx为模运算游标，判空满均依赖qcount，无缓冲时dataqsiz=0且buf=nil。
-
答案：在Golang的RPC开发中，gRPC通过status.Code和status.Error实现标准化错误传递，服务端使用codes.InvalidArgument、NotFound等状态码返回错误，客户端通过status.FromError解析具体错误类型，避免字符串比较；还可通过errdetails附加结构化信息如字段校验失败详情，提升错误处理的可靠性和调试能力。
-
用gobuild-gcflags="-m=2"查看输出，出现“caninline”或“inliningcallto”即成功内联；若含“cannotinline”及原因（如defer、闭包、递归等），则失败；跨包调用默认不内联，//go:inline仅对非接口方法有效且须紧贴声明。
-
select分支执行顺序是伪随机轮询而非随机或按代码顺序；当多个case就绪时，Go以per-Goroutine伪随机起始索引轮询，防饿死但不可预测；default优先级最高，仅有一个case就绪则直接执行，全阻塞则goroutine挂起。
-
测试多线程函数需解决执行顺序不可控、资源竞争和测试提前结束问题，应使用sync.WaitGroup或channel确保所有goroutine完成。
-
gomobile不是UI框架，仅将Go函数编译为AndroidAAR或iOSFramework供原生调用；必须指定合法module路径（不支持.），Android需main包含main函数，iOS需//export注释导出函数。
-
以慢接口排查为线索，讲 Go pprof 的 CPU、heap、goroutine、block profile 使用顺序和常见误判。
-
状态模式通过接口和结构体组合在Golang中实现，将订单等对象的不同状态封装为独立结构体，每个状态实现同一行为接口，如Pay、Ship、Complete；初始状态为待支付，调用Pay后状态切换为已支付，再调用Ship变为已发货，最后Complete进入已完成状态，各状态对操作返回不同结果并控制状态转移，避免了冗长条件判断，新增状态只需扩展新结构体而不修改原有代码，符合开闭原则，提升了可维护性与可扩展性。
-
直接测handler函数时用httptest.NewRecorder；需完整HTTP生命周期（如重定向、中间件、TLS）才用httptest.NewServer。前者轻量快速，适合90%单元测试；后者启真实服务，易致端口冲突、变慢，属集成测试范畴。
-
Gomap迭代不按插入顺序是设计使然，旨在防止依赖顺序；其底层从随机bucket和cell开始遍历，每次range起点由运行时动态生成；需有序遍历时应先提取key切片并排序。
-
直接用Eval容易出错，因go-redis的Eval要求*redis.Script实例而非字符串，且keys和args必须严格分离为[]string和interface{}切片，否则导致类型错误、越界或脚本内无法访问参数。
-
Go语言通过反射可动态获取结构体方法，核心是使用reflect.TypeOf获取类型对象，再调用NumMethod和Method遍历方法；需注意值接收者与指针接收者差异：值类型只能访问值接收者方法，而指针类型可访问两者；通过reflect.Method可获取方法名、类型签名及函数值，进而实现动态调用。
