-
Go1.11后GOPATH非必需，但goinstall、旧工具、vendor模式、golist反射操作及部分IDE仍强依赖它；推荐显式设独立GOPATH并加入PATH，避免与GO111MODULE冲突。
-
Go标准库net/ftp仅提供FTP客户端和ServerConn（服务端视角的连接管理），未实现完整服务端逻辑，故无法直接启动FTP服务器；需用github.com/freddierice/go-ftp-server等第三方库。
-
不能靠单机内存实现多节点Session黏性路由，必须依赖外部一致性哈希或LB原生sticky机制；因sync.Map仅保障单机并发安全，无法同步集群状态，且受NAT/CDN导致IP失真、服务重启丢数据、映射不一致等影响而完全不可行。
-
应复用切片、小结构体优先传值、合理使用sync.Pool、谨慎字符串转换，并通过-gcflags="-m"和pprof验证逃逸与内存分配。
-
不能直接用interface{}写Max，因为会触发运行时类型断言和反射调用，无法编译期校验可比较性，也不能进行数值运算，且丧失类型推导能力；应使用泛型约束如constraints.Integer|constraints.Float。
-
replace指令用于替换模块依赖路径或版本，常用于本地调试、私有仓库代理等场景。语法为replaceoldModule=>newModule或指定版本，支持本地目录或远程模块替换，仅在当前项目生效且不传递下游，开发完成后建议移除。
-
Go反射获取方法需用reflect.TypeOf(obj).NumMethod()和Method(i)遍历导出方法；指针接收者方法须传指针类型；调用前须用IsValid()检查，且参数需包装为[]reflect.Value；非导出方法不可见不可调。
-
gotest-bench不适合测HTTP服务吞吐量，它绕过TCP栈、TLS、连接池等真实链路环节，仅适合纯计算或本地I/O的Benchmark；真实压测应使用vegeta或wrk并禁用Keep-Alive，gRPC应用ghz，同时必须采集pprof数据并验证服务端实际处理状态。
-
能改，但极不安全：绕过编译检查直接操作内存，易致崩溃、GC异常、字段对齐错误或逻辑失效，应优先使用setter、反射（限包内）或封装wrapper。
-
最安全的WebSocket消息处理方式是定义结构化容器+json.RawMessage延迟解析，配合接口路由和错误链包装。
-
go:generate是Go官方提供的标记驱动代码生成触发器，需手动执行，适用于重复性高、结构固定的场景（如protobuf生成gRPC、枚举生成String方法），不自动运行、不参与构建流程，但可与Go脚本深度集成实现可复现、跨平台、零依赖的自动化生成。
-
不推荐在单个容器中运行多个Go服务。应遵循“一个容器一个进程”原则，采用独立容器+自定义bridge网络+环境变量注入地址的方式部署多服务，Go程序需监听0.0.0.0:$PORT并避免DNS缓存问题。
-
享元模式在Go中本质是对象复用而非并发安全银弹；sync.Pool最接近但不等同经典享元，要求对象无状态或可重置，共享状态须不可变，外部状态由调用方传入。
-
strings.Replacer适合什么场景批量、无重叠、纯字符串替换——比如把日志里的敏感字段password、token、api_key全替成"***"，或者统一修正一堆旧API路径前缀。它不是正则，不支持模式匹配，也不处理重叠替换（比如用"ab"→"x"和"abc"→"y"同时存在时，"abc"不会优先匹配长的）。常见错误现象：strings.Replacer对输入不做任何预处理，如果原始文本里有换行、空格缩进不一致，或大小写混杂，它就原样比对——结果就是“明明写
-
Golang中实现RPC认证需结合TLS加密与JWT校验：TLS保障通信安全，JWT验证身份权限；服务端用credentials.NewTLSFromFile加载证书，客户端配置根证书；通过gRPCmetadata在authorization头透传JWT，并用UnaryInterceptor统一校验；可选mTLS双向认证增强信任，Token应短时效并配合刷新机制。
