go 语言实践:命名规则




用 slice 实现栈和队列几乎是 Go 入门练习里的必做题。因为语法不复杂,append 也足够顺手,所以很多人会觉得这类题没什么难度。但真正把它写进稍微像样一点的小程序里时,你会发现问题并不在“会不会写”,而在“有没有考虑清楚容量变化、出队后残留引用、空结构操作这些细节”。
很多人刷算法题时喜欢挑复杂题,觉得这样更有挑战。但从练代码基本功的角度看,真正值得反复写的,往往是那些规则简单、边界丰富的小题。递归和二分查找就是这种题型的代表。它们不靠花哨技巧取胜,却非常适合训练你是不是能把停止条件、输入约束和函数职责写清楚。
Go 标准库里的 encoding/json 已经够用了,平时做接口、配置读取、消息体解析,大多数场景都离不开它。问题在于,很多初学阶段写出来的 JSON 代码“能跑”但并不稳。真正进入接口联调或者服务之间互相调用时,字段命名、默认值、空值含义这些细节很快就会冒出来。
刚开始写 Go 的时候,遇到文本拼接最容易想到的还是 +。代码少时当然没问题,但一旦进入循环、日志拼接、模板前处理或者接口响应组装,这种写法很快就会让代码既不清晰,也不够稳妥。真正开始做一些小工具之后,我发现自己最常用的其实不是花哨技巧,而是把 strings.Builder 和 bytes.Buffer 的边界分清楚。
Go 里的方法接收者,看起来是一个很小的语法点,但一旦项目写久了,你会发现它会直接影响代码语义。很多人会背口诀:能不用指针就不用指针,或者一旦要改值就用指针。可真正到工程里,光背口诀还是不够。
刚从 GOPATH 思维切到 Go Modules 时,很多人最直观的感受是目录终于自由了,不一定要把项目放在固定路径下。可真正让我觉得它实用的,是本地联调依赖仓库时,不用再靠复制粘贴代码或者临时改 import 路径硬顶过去。
Go 初学阶段很容易把 slice 和 map 当成“比数组和字典好用一点的容器”。真正开始写业务后,很多让人困惑的 bug 其实都和这两个基础类型有关:为什么函数里改了 slice,外面数据也变了;为什么 map 还没赋值就 panic;为什么看起来只是截了个子切片,内存却迟迟下不来。