复盘我在 Go 服务里拆分职责、收敛依赖和降低变更风险的几个实际做法。

目录结构的目标不是看起来完整，而是让新需求进入时不会立即打破原有边界。

技术分享更有价值的部分，往往是问题背景、权衡过程和失败记录，而不是结论本身。

接口层、服务层和下游客户端都能设置超时，但真正稳定的做法不是每层都随便加一个数字。

从索引、执行计划、缓存到调用链，我把常用排查顺序整理成了一个固定清单。

缓存命中率、失效策略和一致性成本，如果不提前想清楚，Redis 只会把问题藏起来。

很多排障问题并不是监控不够，而是日志结构长期不统一，导致上下文无法串联。

AI 适合加快试探和整理，但系统边界、代码质量和最终取舍仍然需要开发者负责。

错误码如果只是临时补出来的字符串，最后会变成客户端和服务端都难以维护的灰区。