这种情况，最好公司内架个代理入口。
现在需要用到代理的情况多了去了，不单单是 docker 拉镜像。
什么系统更新，拉取依赖，软件更新，项目维护的出口分流等等，几乎都要用到代理。

@hack2012
OP 那边不知道。但按照江南部分地区的说法，如果彩礼啥的都不要，就算是两家并一家，那么孩子基本会搞成 2 个姓。
不然女方那边就会觉得，自己的香火断了。

@whoosy
病不在于你会不会死，而在于生病过程中，自己经历的痛苦和照顾你的人经历的痛苦。这些都是相当煎熬的。
这种感觉类似某些影视剧里，你被敌人抓起来严刑拷打个几年。
最后你真的什么都不想要了，只求一死图个痛快。

@fredweili 凭本事吃饭的另一面就是学习压力特别大。几乎比所有其他行业都大。
等哪天软件发展遇到瓶颈了，或者说高精尖的编程技术一个人或少数人无法尽数掌握，需要靠团队时。程序员就没法靠本事吃饭了。

@me1onsoda 你们用啥语言？

你们服务端招什么语言的？

这个优惠好及时啊，正好差几天到期。

@VchentozV 就我的经验可以回答你上面几个问题。
Windows 高性能笔记本不像 Mac ，面子只和价格正相关，也就是大厂的高端本。比如移动工作站，或者华硕 ROG ，联想拯救者至尊版一类的。联想 think 系列凭以前的积累也算在商务本上有点辨识度。HP 啊机械革命啊，品牌辨识度还是不够。公众场合吸引不了注意力。
笔记本你需要考虑售后。就我用过的 N 台笔记本来说，故障率都不小。价格合适，我现在都会考虑买上门保修。这样不用请假去维修，等待时间也比较短，硬盘里的数据也不担心被窥探。
风扇噪声会影响别人办公。我已经被同事善意提醒了 N 次了。现在我逐渐转台式机了。
散热是否烫手要看各个笔记本的设计。但真正的问题是
散热是笔记本性能释放的重灾区。很多笔记本看起来是一样的 CPU 显卡，但性能相差很大，几乎都是散热的原因。这个要仔细看评测和别人的使用体会。

做什么用？如果是开发，就选个大众点、口碑好点的游戏本。
笔记本因为功耗和散热限制，即使和台式机同规格，性能也要落后台式机一截。平价点的高性能也就 i5 和 4060 级别了。再往上就没有性价比可言。
电子产品有几率损坏是必然的事情。不能指望肯定不折腾。而且即使口碑好的牌子，也不能保证厂商设计时不犯错。前几天我笔记本键盘某个键坏了，维修时竟然要把整机拆了才好修。我当场惊呆了。

有没有排查过是否跨运营商了？
Tailscale 直连是 UDP ，走中继是 TCP 。我这边就遇到跨运营商后 UDP 各种不稳定。要到半夜以后才能缓解。

挺好！
有时候看着别人过得好，自己心里也舒畅。
这年头悲观消息太多了。让人很不自在。

我去年搬家，新家没有入户光纤。联通的安装师傅带了冲击钻，免费帮我钻墙穿光纤入户。
搞不懂你那的联通怎么回事。。。

@jixiaopeng 我觉得，相比你问的这个问题，你可能更要想清楚，自己当前的经济情况、个人能力是否适合和别人一起创业。
开公司是个失败率很高，非常耗费个人的时间精力，也非常考验个人的经验和能力的事情。

我不确定你想参与的事情有多大。

如果是小打小闹。完全不需要担心你的说的这个问题。因为摊子很小，随便找个老婆亲戚啥的，参与进去，就几乎不用担心你说的风险。
如果是看到机遇，准备搞个大的。那相比你说的这个问题，我更担心你跟别人一起单干的风险。以你的经验啥的来说，感觉有点悬，要趟的坑很大。

一种是找到靠谱的国内镜像源，然后 daemon.json 中配置 registry-mirrors ，指向这个镜像源。

另一种是在运行 docker 的那台机器上添加配置，让 docker 的 daemon 走代理访问官方源。
这种方式假定你已经搭建了代理服务器。
具体可以看下这篇官方的文档。
https://docs.docker.com/config/daemon/systemd/#httphttps-proxy

我本来想从严肃的人性角度回答这个问题，安慰下 OP 的。
但突然发现这个在程序上是个多线程访问共享资源的竞争问题。
所以 OP 你也有责任！
你访问一个共享资源，在不清楚是否有其他线程访问这个资源的情况下（关着门），没有加`if`判断进行验证（你没敲门！），就擅自访问这个共享资源了！这是线程不安全的。然后你中招了。

当然，人不是机器。世界是复杂的，每个人都有自己的喜好和厌恶。从便利性、舒适性、人与人之间是熟悉还是陌生。你问的问题没有统一的答案。放在不同环境，不同做法都有可能是可以的。
多出几次错，大家就默契了。
可能到时候，所有人都无所谓臭味，用完就开着门。关着门时，默认里面有人。
或者大家都很讲究，默认门应该关着，然后自己进去就上锁，其他人要用就敲门。

还有嘛，这世界是草台班子组成的。讨论啥规矩都没用。每个人都毛糙的不行，都按照最方便的方式行事，不撞几次墙不会改正。

@kneo 嗯，我记错了。有一段时间没写后端了。
我们团队里面，各种原因，kotlin 的特性也没有用的很深。只是觉得写起来比较简短和自由。当然，kotlin 的一大缺点就是编译时间太长了。