罐装我理解会随客单送一罐（正常也够用的），更多需要收费。收费应该在客人提的时候就说明。

关键字：continuous testing

FYI gradle 更适合干这个事情。

不看看劳动合同怎么约定吗？我的是合同成立期间一切指定领域的产出归属公司（这个指定领域的范围相当之广）。

我觉得还是大部分人的视野被各种因素局限，我们生活中能看到的文化产品大部分来自东大，小部分来自西大和日韩，欧洲、亚洲其他区域、非洲、拉丁美洲的占比加起来可能都比不上日韩，这些地方的人口可没那么少，对很多宏观问题的直觉就很容易出问题。

现在 FFM 已经很好了，底层库也不应该过多考虑用户交互层面的事情，可以看下 jextract ，我自己是觉得足够好用了。

我是经常收到招行的类似电话，忙着就直接挂掉，有空就让他在招行 app 上给我发消息。

你为啥把工资交了但是不把存款也转了，是不是不信任她在留退路？

@youngxxx 我倾向于是黑灰产通过某种方式把审核模型搞崩之后大面积上线违规内容。把模型搞崩的方式就不清楚了，有可能是内容投毒，也有可能是利用了某个 0day 。具体还得等官方或者快手内部调查的结论。你这个人工瓶颈的理论过于不合理，制度设计导致某个流程依赖某个单点的人，这个单点的人出车祸都比你这个合理。

使用 Java 的有没有用过 eclipsestore ，基本上可以实现 OP 说的这个效果

快手这次显然不是自动审核机制缺位导致人工过载，如果真的有人类介入，事情怎么可能搞到这个程度。

快手明显是过度依赖模型审核，导致模型雪崩之后后台失去了对线上内容的控制，甚至都没有及时报警让人介入。

快手这次是风控和运营策略的失败，和审核没什么关系。

@5261 不会。

golang 程序员经常吐槽的 spring/java 味通常是指冗长低效的逻辑嵌套，比如封装 Accessor Methods ，堆叠套用各种工厂模式，还有屁大点事都要 New 一个对象。
这些是代码里的坏味道，但这是程序员的问题，不是面向对象的问题，假如有人看到面向对象的东西，就说这是 java 味，那是这个人的问题，不是代码的问题。
使用 fx 这样的 DI 框架，你首先就需要接受面向对象这个编程范式，这是个好东西，绝对可以帮你们消除混乱的全局状态，管理好应用的生命周期。
如果你们团队里有比较好的 Java 积累，我估计你们大概率确实会在 golang 里复刻一些在 java 里很常见的设计模式，这可以说是 spring 味或者 java 味，我觉得不是坏事，用 golang 的语法大概率可以写出更地道的代码，但能被大家理解，能解决问题，足够稳定的代码就已经是好代码了。

@5261 我的观点是要用 golang 写上规模的微服务，是必须结合 k8s 的平台能力，这不是优点，是 golang 语言生态的缺失，当然这个路子很多公司在走，也很顺畅。

golang 还可以用来写单体服务，写客户端应用，甚至写游戏，这个语言绝对是一个设计优秀的语言，没有 k8s 也能用它做很多事情。

shell 执行 `open -n Your.app`。

既然你用 aerospace ，就直接绑定一个快捷键执行 `exec-and-forget <open -n Your.app>` 就挺好，Alfred 的 shell 环境变量不太好配。

@5261 那我就直接点，你列的这堆 AI 写的东西，不是 golang 和 java 语言的差异，更不是 golang 比 java 更优的地方，充其量是典型 Google 技术栈和典型 Spring 技术栈的差异，而且这段东西暗示的 golang 更优这件事情是不存在的。

你不是很懂 Kubernetes ？你列的 golang 这堆平台能力就没有哪了是能离得了 Kubernetes 的，你不懂 Kubernetes 咋用它们？就“云原生”“用平台”听起来很帅气？一点成本都没有的吗？

自己不懂 Kubernetes 也没有靠谱的运维团队帮你玩转这一套，就“用平台”，“移出代码”？
有运维提供平台能力，spring 这一套确实臃肿不堪，但是 Java 生态那么多框架，为啥指着 spring 的不足就要转 golang 呢？

---

golang 简洁无糖的语法，天然的协程支持，简洁好用的并发同步机制（ channel ），极小的运行时，某种程度上更优的跨平台能力这些东西你不夸，还你写的代码有这味，咋的你能把平台能力封装进 golang 的框架呗

重写的 hashCode/equals 方法应该是默认实现的上位替代，所以你的“在使用的过程中如果不知道这个类复写了 hashcode ，那么就容易导致代码问题”是不成立的。

而由于默认实现的天然缺陷（容易把两个逻辑同一的对象当作不同对象）——考虑经典面试题 Integer 池和`new String("")`——在可能作为 Map 的键或 Set 元素的场景中重写 hashCode/equals 是必要的，对于关键的数据对象（如包含 id 字段的 User 实体类），你无法预见它们的使用场景，因此当然应该重写。

我觉得这俩思路和语言关系不是很大。
golang 因为比较新，它出来的时候 Kubernetes 就是微服务的事实标准，服务网格也方兴未艾，所以很多工具直接就走这一套，其实现在用 golang 写的注册中心、配置中心也不老少。
Java/Spring 太古老了，几乎能在里面找到历史上所有微服务解决方案的影子，搞到今天这个地步，复杂度我觉得是已经到了离谱的程度，有识之士基本上都在另起炉灶（ micronaut quarkus helidon, etc ）。

对有靠谱运维且技术栈较新的团队，还是别用 spring 那套了。