-
Go语言类型推断仅发生在短变量声明（:=）且至少有一个新变量时，编译器根据右侧表达式默认类型静态推导，如a:=42→int、s:="hello"→string，不支持隐式类型转换。
-
Go原生不支持JSON并行解析，json.Unmarshal和json.Decoder均为单goroutine同步操作；真正有效的并行仅适用于可分片的独立JSON数据，如JSONLines、预分割数组或流式响应中的完整对象，而单个嵌套JSON对象不可强行切分。
-
Go语言RPC性能优化需多层协同：首选ProtocolBuffers等高效序列化协议，精简数据结构，启用gRPC压缩，复用连接并支持批量调用，且必须基于真实数据压测验证效果。
-
Go语言中if和switch用于分支控制，if可带初始化语句，作用域限于块内，支持else-if链；switch无需break，支持表达式、多值匹配、无表达式条件判断及类型断言，推荐用switch替代复杂if-else以提升可读性。
-
Go程序在容器中CPU跑不满是预期行为，因其默认GOMAXPROCS设为宿主机CPU总数而非--cpus限制值，导致P数远超实际配额，引发调度争抢与CFSthrottling；须主动读cgroup（v1/v2）计算quota/period并调用runtime.GOMAXPROCS设整数上限。
-
推荐用os.Stat+os.IsNotExist判断文件是否存在：os.Stat成功表示存在且可读元数据；err!=nil且os.IsNotExist(err)表示确实不存在；否则为存在但访问失败。
-
SQLite在Go中嵌入需卡死三步：启用CGO（否则编译报undefinedreference）、DSN用绝对路径并确保父目录存在、db.Ping()后显式执行PRAGMAforeign_keys=ON/journal_mode=WAL/encoding='UTF-8'。
-
lumberjack.Logger是最省心的日志切割方案，但仅支持按大小和按天轮转，不支持按小时、按分钟或自定义时间点切割；需显式设置Mode:0644保证可读性，并注意父目录存在、Windows文件占用、并发写入优化等问题。
-
gRPC流式传输传大文件易卡死或OOM，因Unary调用将整个数据加载内存；须用BidiStreaming分块传输，客户端需手动分片Send，服务端须及时落盘而非缓存。
-
Golang中反射Implements方法的核心作用是动态判断具体类型是否实现了某个接口。1.它检查的是类型定义层面的契合，而非具体值的实现；2.通过reflect.Type上的Implements方法传入接口类型参数进行判断，返回布尔值表示是否实现；3.与类型断言不同，Implements操作的是类型元数据，适用于框架、插件系统等需要动态判断类型的场景；4.处理接收者差异时严格遵循Go规则：值接收者方法使类型T和*T均满足接口，指针接收者方法仅*T满足；5.性能上相对耗时，不适合高频路径，建议用于初始化
-
在Golang项目中实现用户认证的常见方式包括JWT无状态认证、Session会话管理和第三方OAuth登录。1.JWT适用于前后端分离架构，流程为：验证用户信息→生成Token→客户端存储并携带至Header→服务端解析验证Token，常用库如auth0/go-jwt-auth；2.Session机制适合非前后端分离项目，通过Cookie维护SessionID，服务端存储状态，使用github.com/gorilla/sessions库管理；3.OAuth2用于集成微信、Google等第三方登录，流程包
-
gqlgeninit卡住或报错modulenotfound，主因是Gomodule未初始化或GOPROXY配置失效；需先gomodinit、设有效代理、避免GOPATH混用，并确保schema与gqlgen.yml配置一致。
-
setsockopt(IP_TRANSPARENT)返回operationnotpermitted的根本原因是未在bind前设置且缺乏CAP_NET_RAW权限；必须用syscall手动创建socket、设选项、bind、listen，并配合TPROXY规则与策略路由。
-
Go语言中正则表达式的性能优化，核心在于避免重复编译——每次调用regexp.Compile都会解析、验证并生成状态机，开销显著。最直接有效的做法就是预编译+缓存复用，尤其在高频匹配（如日志解析、HTTP路由、输入校验）场景下效果明显。预编译：用regexp.MustCompile替代regexp.Compile如果正则表达式是固定字符串（即不依赖运行时变量），应使用regexp.MustCompile在程序初始化阶段一次性编译。它会在编译失败时panic，但换来零运行时错误
-
WebSocket通过心跳检测与断线重连机制提升连接稳定性，客户端每30秒发送ping，服务端回应pong，超时未响应则判定断线；onclose触发后按指数退避策略重试连接，最多5次，确保网络波动后可靠恢复。
