一介布衣

Go 标准库里的 encoding/json 已经够用了，平时做接口、配置读取、消息体解析，大多数场景都离不开它。问题在于，很多初学阶段写出来的 JSON 代码“能跑”但并不稳。真正进入接口联调或者服务之间互相调用时，字段命名、默认值、空值含义这些细节很快就会冒出来。

刚开始写 Go 的时候，遇到文本拼接最容易想到的还是 +。代码少时当然没问题，但一旦进入循环、日志拼接、模板前处理或者接口响应组装，这种写法很快就会让代码既不清晰，也不够稳妥。真正开始做一些小工具之后，我发现自己最常用的其实不是花哨技巧，而是把 strings.Builder 和 bytes.Buffer 的边界分清楚。

Go 里的方法接收者，看起来是一个很小的语法点，但一旦项目写久了，你会发现它会直接影响代码语义。很多人会背口诀：能不用指针就不用指针，或者一旦要改值就用指针。可真正到工程里，光背口诀还是不够。

容器化本地开发有一个很常见的问题：服务虽然都起来了，但互相调用时用的地址特别随意。今天写死一个容器名，明天改成宿主机端口，后天又因为换了 compose 文件把连接地址全部推倒重来。结果是，本地联调环境虽然能跑，却总和线上长得不太一样。

刚开始用 Sequelize 的时候，模型定义很像一件机械活：写字段、配表名、导出模型，就结束了。可项目一大，模型之间开始出现 belongsTo、hasMany、belongsToMany 这类关联之后，我越来越觉得“模型怎么注册、谁先初始化”已经不是小事了。

很多人第一次排查 Docker 容器问题，都会先看日志。这一步当然没错，但如果只停在日志层，很容易卡住。因为容器问题经常不是单点故障，它可能同时涉及启动参数、挂载路径、网络配置、环境变量以及容器内部运行状态。

很多项目第一次做 webpack 缓存优化，都会先把文件名改成带 hash，觉得这样浏览器就能长期缓存了。这个方向没错，但如果 chunk 划分本身不稳定、运行时代码老是跟着变化、公共依赖和业务代码混在一起，最后会发现缓存命中率并没有想象中高。

webpack 配 source map 时，很多人最开始只有一个判断标准：能不能在浏览器里看到原始源码。可项目一大以后，你会发现 source map 其实牵连了很多事，构建速度、调试精度、错误定位、产物暴露范围，全都和它有关。选型如果只看“调试爽不爽”，很容易在发布阶段踩坑。

webpack 开始提示包太大以后，很多人的第一反应是“那我多写几个 import() 吧”。动态导入当然是重要工具，但如果拆分点没有顺着页面路由和功能边界走，只会把一个大包拆成很多难管理的小包，首屏和切页体验未必真的更好。

webpack 的性能优化很容易让人一上来就陷入“经验动作”：先怀疑 UI 组件库，再怀疑图片，再想办法加几个拆包配置。可如果还没看清产物里到底是什么占了体积，这些动作大多只是碰运气。真正有效的优化，通常都从一份可读的打包分析开始。