@Raynard 这个倒是也看过。手动暂时没 windows 电脑，就没试过。

Eslint 我感觉编写代码的时候，最好就别开启。影响写代码，配置到 precommit githook 里，提交的时候再检查。

能 auto fix 的，尽量 auto fix ，无法 auto fix 的，再报错拦住 commit 。

看你有没有经验了。建议直接找专业的修。

我上次换键盘线路膜，从晚上 8 点，折腾到凌晨 2 点多。还剩余好几个螺丝没拧进去。最后还能用 只能说是运气使然。

这种需求自己改一下快捷键。

可以把 `search.action.focusNextSearchResult` 的 when

从 `hasSearchResult || isSearchEditor`

改成 `!(reference-list.hasResult && references-view.canNavigate) && (hasSearchResult || isSearchEditor)

简而言之，`search.action.focusNextSearchResult` 排斥掉 `references-view.next` 的 when 。

mac 兼容吗？ 上链接，鼠标键盘都要。

mac 的容器化，都是在虚拟机上进行的，跑起来性能打折。何苦用 mac 。

@cocong 所以说，教条才是永恒。

“反正我跟你说好就是好”
“你看，这个函数多纯啊！”
“你看，我们能动态绑定，多灵活。”
“你看，我们现在摆脱动态绑定了，多纯粹”。

我现在对“语言软文贴”避而远之。

个人实在不喜欢函数里声明大量函数的做法。

感觉一打开一个函数，就要先面对大量的“子函数”实现细节，然后才能看到函数本身的逻辑，这个跟你提问的苦恼一样。我感觉组织这种逻辑，还是 class 最适合。

网龙吗？

年终奖现在真的不能信。年底了，拿年终当优化费用。

@BeautifulSoap 说到交叉 build 。我之前遇到一个镜像架构的问题，一个感受是这方便的定义貌似比较混乱。不知道这样感觉对不对，有的用 tag 区分，有的定义在 manifest 里。docker pull 有个 --platform 参数，但是自己试了没用。

感觉遇到“镜像标准”相关的问题的时候，比较摸黑，解决起来没太多思路。镜像的标准应该怎么学？读 https://github.com/opencontainers/distribution-spec/blob/main/spec.md 这玩意吗？

@BeautifulSoap 我感觉这玩意主要是给企业用户使用的，个人用 DInD 省心多了。一些需求，对企业用户来说感觉不迫切，反正有的是资源，所以也没动力去做。

我之前也是使用 DInD ，之所以折腾这玩意，只是为了实践公司的工具链。

@perfectlife 嗯，最主要的就是从基础镜像要跟 ci 在一个区域。


@jackge0323 会不会也是被 ignore 了？可以加上 --verbosity=trace 参数看看更详细的日志信息。

@trumandu 有时候也会陷入这种“无意义”感之中。我个人是写的代码没有带来什么“业务效果”之后，会有这种感觉。有时候我也安慰自己说“这不是我能决定的”。

送你《球状闪电》里的一句话。

“全身心的投入，只问耕耘不问收获，只享受过程不在乎结果，想想就很美妙——美妙人生的关键在于你能迷上什么东西”。


“儿子，过一个美妙的人生并不难，听爸爸教你：你选一个公认的世界难题，最好是只用一张纸和一只铅笔的数学难题，比如歌德巴赫猜想或费尔马大定理什么的，或连纸笔都不要的纯自然哲学难题，比如宇宙的本源之类，投入全部身心钻研，只问耕耘不问收获，不知不觉的专注中，一辈子也就过去了。人们常说的寄托，也就是这么回事。或是相反，把挣钱作为惟一的目标，所有的时间都想着怎么挣，也不问挣来干什么用，到死的时候像葛朗台一样抱者一堆金币说：啊，真暖和啊……”这些天一直在思考关于追求与理想的话题，而书中开头的一句话就触动了我的内心，因为这和我的思考不谋而合。果然是问题太多，读书太少，前人已经把太多的精华留在书里。全身心的投入，只问耕耘不问收获，只享受过程不在乎结果，想想就很美妙——美妙人生的关键在于你能迷上什么东西”。

@justdoit123
加个「狗头」

去重新配一副眼镜就能掌握了。

先前跟同事写一个要营销页面。我跟他说，你就 v1 、v2 、v3 这样一直命名下去就好，前后端代码都这样命名。不要想着复用。

这种营销页面，果然写了整整 5 个版本，到了 v5 。每个版本的逻辑、UI 结构都出入较大，难以复用。

这要是一开始就在那边思考怎么通用、怎么易扩展，可想而知会有多痛苦。

工作中的一些需求，一看就能知道是实验性的、试探性的，这种东西别想着去抽象复用。

另一个例子，是我们的 UI 团队。一个人一个风格，上来一个 UI leader 就要订一套 UI 规范。我以前还乖乖听，写过两个版本的 UI 组件。后来就不鸟了。当然，我不是说 UI 组件不用抽离，规范稳定的 UI 设计语言，很值得沉淀组件。我们这种信誓旦旦的说 “以后都这样”，但是实际活不过一周的 “UI 规范” 当屁话听就行。

埋点关注。

我的实践经验感觉 RN 深入后，不会 Native 就很被动。

@eephee 按你的描述，感觉应该先解决这个分布式有状态扩缩容问题。 然后你这个问题可能就不是什么问题。

楼主可以再深入描述一下，业务的细节，这样其他人可以给更好的建议。

另外，想请教一下 "一致性哈希以达到 对于特定的 URL 的请求，固定转发到唯一的副本。" 这个需求，在扩容或缩容之后，如何保证之前的请求，依然分流到之前的副本？