-
大量time.Ticker或time.Timer会显著增加Goruntime调度压力，因其共用全局最小堆管理，高频增删导致timerproc负载升高，影响GC和调度；应复用单ticker、及时Stop、优先用AfterFunc。
-
本文详解如何在Go中不依赖指针解引用技巧（如(*T)(nil).Elem()），安全高效地从结构体类型获取reflect.Type，并基于该类型动态创建泛型切片，适用于数据库服务层等无Schema场景。
-
Go的string底层只读，直接用unsafe.String修改会触发panic；安全做法是先转为[]byte再修改，或确保源内存可写且无其他引用。
-
Go语言通过sync.Cond结合互斥锁模拟条件变量，用于goroutine间等待条件成立，需用for循环防范虚假唤醒，典型场景如生产者-消费者；相比channel，它适合多协程等待同一条件或需细粒度唤醒控制。
-
Golang切片本质是包含指针、长度和容量的结构体，传递时复制结构体但共享底层数组，因此修改元素会影响原切片，而append是否生效取决于是否扩容及是否返回赋值。
-
日常调试用log.Println，结构化日志必须用log.Printf；需时间戳和行号则设log.SetFlags(log.LstdFlags|log.Lshortfile)；写文件要用os.OpenFile并检查err；分级和上下文需换zap/slog。
-
Reflect.DeepEqual常返false因严格校验类型、零值及不可比字段；禁用场景包括需忽略字段、浮点容差、含mutex、性能敏感；安全比较slice/map需标准化；业务相等应自定义Equal方法。
-
rand.Shuffle是当前最稳妥的选择，因其基于Fisher–Yates算法、线程安全、不依赖全局随机源，且避免了手动实现的边界错误和并发panic。
-
pdfcpu提取中文文本需配置fontmap.yml指定中文字体绝对路径，嵌入字体时无效；Go调用需设Conf.FontMapFile，返回文本页间以"\f"分隔；unidoc过重且有许可限制；加密PDF仅owner密码阻断提取。
-
应使用json.RawMessage跳过不必要的解析，仅在需要时解构；结合sync.Pool复用结构体减少GC；优先用json.Decoder处理流式或大JSON；替换标准库为easyjson或go-json以规避反射开销。
-
Go语言无原生热编译，所谓“热编译”实为工具（如air或nodemon）监听文件变化后自动构建并重启进程；常见问题包括路径配置错误、未监听非.go文件、Windows文件锁及模板/配置未重载等。
-
gvm命令未找到是因为初始化脚本未加载，需手动将source~/.gvm/scripts/gvm加入~/.zshrc或~/.bash_profile并重载；安装慢需手动下载二进制包配合--binary参数；GOROOT异常需检查环境变量与IDE缓存；多语言场景可选asdf，但gvm对Go更专一稳定。
-
go版本
本文go版本是1.14，开启 GO111MODULE="on"
经常在go.mod里面看到引入第三方库的版本号：
module test
go 1.14
require github.com/jinzhu/copier v0.3.5 // indirect
可以看到copier版本使用的是v0.3.5的版本。
-
引言
Go 的错误处理一直是表现最突出的一块地方，许许多多的同学都提出了各种提案，例如：引入 try-catch、用 panic 代替 if err != nil、引入新的关键字等。但这些都被一一驳回了。
不过社区依然
-
其实对于追求简单来说，Golang标准日志库的三个输出方法也够用了，理解起来也很容易：
Print用于记录一个普通的程序日志，开发者想记点什么都可以。Fatal用于记录一个导致程序崩溃的日志，
