前方一片坦途前提下 -> 提速

前方一片坦途你也不想提速：
如果右边车道满足后车超车条件 -> 保持
如果右边车道满足变道条件 -> 变道

其余，保持

@Corrots 这里有两个问题：
一是对实际情况来说采样率开不开到 100%只是采样，和埋点没有啥关，这里和性能应该也扯不上关系。
二是对性能的影响需要有数据来论证，并且是结合楼主实际业务的。比如添加了这些埋点后，性能指标有什么变化？

另外对性能影响的大小是由埋点决定的，那么也就是说具体对性能的影响是可控的，因此楼主使用时根据实际情况埋点即可。

这里衍生出来的问题则是，你的服务真的对性能有那么高的要求吗？如果是，那么你的这个服务的业务逻辑本身就应该是很薄很简单的，而不是柔和了一大坨逻辑在里面。
如果说逻辑本身就很简单很薄，那么埋点数量也必然不需要很多。
如果逻辑本身就很复杂，那么应该讨论的是本身埋点造成的耗时与原本的业务耗时的比例，这个比例我理解也不会高。

最后对于楼主的项目连 OTEL 这类基础设施都没有，要么就是历史久远，要么就是不重要。不重要的概率应该更大，因此这里引入 OTEL 我觉得也不会有什么问题。

现在肯定用 opentelemetry ，Opentracing 已经被废弃了

@FarmerChillax 最好 -> 做好

是不是应该考虑解决方向「为什么重启期间有告警？」
- 是不是没有最好流量无损？

@imherer 我理解 #1 说的 prometheus 是指完整的的 prometheus 监控体系/生态。这确实是目前监控告警的主流

@matrix1010 如果你问的是「依赖注入」，那么基本可以说没有任何一个 Go 项目不使用依赖注入。因为依赖注入遍布了基本所有常用的基础包中。

推荐阅读： https://quii.gitbook.io/learn-go-with-tests

纠正一个点，依赖注入个人认为是一种编程思想，它在 Go 内部包中都无处不在，你问的应该是「依赖注入框架」而不是「依赖注入」。

你说的这些 M720 都能满足！强推这个，和我的需求一样！

当分母✌️

我投 PDM 一票

又到了贴博客的时候了

https://blog.farmer233.top/
https://github.com/FarmerChillax

一楼说的没错，你这确实误人子弟。建议阅读官方 context 文档： https://pkg.go.dev/context#WithValue

一些大型项目/框架中的血泪史：
- https://github.com/gin-gonic/gin/issues/3888
- https://github.com/gin-gonic/gin/issues/4040


最后建议在帖子后面追加说明吧，不然这真的误人子弟

LocalSend

网上的视频就是效率低，更不推荐课程。建议看书，效率最高
新手入门 Web 推荐（： https://book.douban.com/subject/30310340/

更新内推链接： https://xiaopeng.jobs.feishu.cn/s/irGSA3B4

@Niphor 开源工具： https://github.com/regclient/regclient