@iorilu 如果这么比，你应该拿 fasthttp 和 fastapi 比。。。你怎么不拿 Django 和 Gin 比 :p

不如考虑一下这个： https://github.com/oldj/SwitchHosts 还带了环境管理

或许可以考虑一下这么几个方案：
1. 硬盘扩容（相信你的机器早已过保了）
2. 增加一台 Mac mini 作为主力开发，现役作为补充移动场景继续使用

@sunorg 这三个问题分别对应如下：
1. 代码跳转完全没问题
2. 有很多非常不错的三方插件，尝试过几个体验都和 jb 差不多，但个人不爱用这类插件，一般都是命令行为主，故不下结论
3. 代码同步指定到服务器上，我理解这个使用 git 就好了吧？比如使用 git hook ，或者代码仓库接 cicd 等基础功能，而不应该是 ide 这上面做这个事情
当然回归问题本身，技术层面 100%可以实现，功能层面也有许多文件同步插件

Go 和 Python 深度用户，vscode 完全没问题，其余不知道。使用插件：官方插件

目前已经是 4k 了，其实分辨率和刷新率在这个场景下继续提升带来的体验有限，如果是我或许更多的是考虑一下添加一个专门写代码的显示器，比如魔方屏（ 16:18 ）

@liuzimin 如果一个公司卡网盘，那大概率也会卡 usb 设备

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

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

其余，保持

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

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

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

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

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

@FarmerChillax 最好 -> 做好

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

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

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

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

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

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

当分母✌️

我投 PDM 一票