Notes on Agent runtimes — design decisions laid open: why it is this way, what it costs, and when it stops being true.
Quote of the day · October 26 · 关于意义 · Rick and Morty
Nobody exists on purpose. Nobody belongs anywhere. Everybody's gonna die. Come watch TV?
同一份代码,两位开发者看到的诊断结果不同,最常见的成因是两侧 gopls 版本不一致。围绕这一现象,工具链的分工可以概括为:gopls 负责本地已解析的代码与依赖,版本由 go.mod 选定、go.sum 校验;pkg.go.dev 负责尚未进入 go.mod 的包,提供版本、许可证与健康度信息;版本跟进决定前两者何时需要更新。
Go 的注释与文档是同一来源:godoc 与 pkg.go.dev 直接把源码中的文档注释(doc comment)渲染为 API 文档站,不存在 Javadoc 那样"文档一套、注释一套"的双轨维护。由此可得一个直接推论:评价一个库"文档差",基本等同于评价它的注释差——注释之外没有第二个文档来源。
评估一条 CI/CD 流水线的质量,应依据三项客观标准:结果产出速度、结果可信度,以及流水线被攻破后的损失范围。前两项决定开发者是否信任流水线反馈:产出缓慢或偶发误报的流水线会被反复重跑直至通过,日志不再有人阅读。第三项决定仓库在单个被投毒的 action 事件中的暴露程度。
awesome-go 收录的 Go 库数以千计,新框架也不断发布 benchmark 宣称性能数倍于 Gin。但运行多年的项目中,go.mod 保留的第三方依赖通常屈指可数。原因并非开发者刻意克制,而是标准库覆盖面在主流语言中位居前列且仍在加速扩展:Go 1.21 之后,一批由 x/exp 转入标准库的泛型包,已承担许多过去必须引入第三方的职责。
Go 标准库至今不提供通用的 map/filter 集合操作。Go 1.18 泛型落地后,samber 系列是填补这一缺口的主要选择:lo 负责集合变换,mo 负责 Option/Result 类型,hot 负责进程内缓存,ro 负责异步事件流。四个库解决的问题互不重叠,共同特点是零依赖、泛型优先、类型安全,可单独引入,也可组合使用。
在 NewUserService 这类构造函数中直接调用 sql.Open 是典型的反模式:测试无法注入替身,跨环境也无法复用。根源是依赖注入未落实:组件只声明所需依赖,创建与组装由调用方负责。在 Go 中,多数场景的依赖注入不需要库:构造函数传参,main 中逐个创建、按序组装。Java 式注解扫描加运行时容器在 Go 生态中很少见,标准库与主流开源项目的"依赖注入"都相当朴素:装配代码显式可读,启动路径才可预测、可调试。