@dx3759 通顺讲就是要么滚要么忍 hh

@fiypig 差不多了，稍微晚点就 98 了

@beisilu 有的，spring 生态都可以用 kt 开发

@coderluan 公司规定的是“正常”上班时间，还没有算加班时间呢

@murmur 没有离职，还在职的

换个思路，可以把 mac 的键盘映射成 windows 的

正文里说错了，应该是值传递，刚才又想到，对于基本类型和对象的 print 也会显示不一样的行为，基本类型打印值，对象打印的是堆地址，是不是 java 的基本类型没有地址这一说法，还是 jvm 把基本类型的地址隐藏起来了。

是的，之前也发现过一次把软件安装在桌面，卸载后整个桌面被清空，好多文件找不回来，这之后我安装软件都会指定目录，怕了

可以用 restful 的接口风格区分新增和更新，payload 公用在代码上比较省事，就是更新单个字段时请求体会比较大

不放弃淘宝的一个很大的原因是，有些奇奇怪怪的东西你只能在淘宝里买到，其他平台要么没有，要么没有选择的余地

@hunvreus 后端岗位可以联系招聘人员微信投递吗

目前有后端岗位吗

机械革命无解 16 ，已上车 manjaro40 多天，暂时没有出现很大的问题，除了楼上有位兄弟说的，休眠问题确实存在，具体表现为休眠后无法唤醒，优点是价格便宜（ 16g+512g 5000 ）可扩展性强（双内存插槽，双 m2 插槽均可更换）性能还行（ i7-12700H ），屏幕也不错（ 2k120hz ），不介意二线品牌可以考虑入手

我刚加入团队的时候整个项目是没有单元测试的，那时候经常出现改一处问题，又出现好几处其他地方的问题，于是我花了一个月的时间，在项目上搭建了单元测试的框架，并写了第一批测试用例（大约 100 个左右），覆盖了主要业务流程的 6,70%。
对于我来说，单元测试不止有业务迭代，重构时的保障作用，更重要的是，对于修 bug ，测试功能能更快地复现现场。有些功能 /bug 的场景是需要 mq 的，如果在页面上操作需要准备数据，然后经过很多步骤，才能进入待测试方法，而且本地调试很容易误消费消息，带来很多干扰。如果用单元测试，我只需要准备消费者需要的对象，然后在测试方法里调用即可。
我写完第一批测试用例，在团队内推广单元测试的时候，大部分同事也是抱着业务迭代紧，没时间写的想法，也几乎不会去写新的测试，直到后面出现 bug ，我教他们如何复现，如何验证，然后他们也开始觉得测试也挺好用的。
当然我能做完这一切的原因是，我刚加入的时候完全没有需求的压力，只有修复 bug 的任务，所以我才能一边修 bug ，一边验证这一套单元测试的框架。
所以，如果你的团队完全没有意识到测试的重要性，也完全没有给单元测试安排时间，那么建议还是放弃单元测试，让测试人员去做，除非你能说服领导单元测试的好处，能在每次迭代中留有单元测试的时间，那可以在团队中尝试加入单元测试

可能不是自己的 ipad 所以不在意

1. 你只是把 A 的代码合并进来了，所以 B 会有 A 的所有代码，2 个分支不一定一样。
2. 你是不是没有推送提交到 B 分支，在合并 A 之后需要 push origin B 后，其他人才能拉到改动。

pc 和手机还有个区别是 pc 有硬盘这个概念来表示存储空间，几乎不会有人把内存和硬盘搞混，但手机上的内存就比较模糊了，除非厂商们把存储空间统一称为硬盘，这样内存就能回归本来的含义了。

@enjoychen0318
@7911364440
@iXInbo
如果单纯是 inner join 的话，感觉驱动表大小不会影响最后的结果吧，nested loop join 下，外面 for50 次，里面 for100 次跟外面 for100 次，里面 for50 次在 cpu 运算上好像没有区别，在数据量比较小的例子下，io 层面也是一样的消耗