苹果的取舍是：宁愿整个刘海也不给摄像头减配甚至要增配（虽然我觉得这个摄像头的性能完全 overkill

虽然并不买……
但是要买的话会选 16 ，因为手头有另外一部 13 寸满足移动的需求，16 寸更多的时候其实当台式机用，偶尔拎走，所以重量不是问题

> 而且 V2EX 大部分都是程序员，其实大部分程序员用 MacBook Air 也够了。

你要说 m1 air 满足 curd 需求或者远程开发我还能勉强接受，但是程序员啥需求的都有，啥场景都有，我身边的几个做专业软件开发的，内存 128g 都不够用，怎么可能一个 air 默秒全

感谢苹果和 amd 让大家用上了性能更强的 intel

感觉不太合适
肯定需要一个确认的动作，不能看一眼就直接解锁
直接用指纹不就是这个效果么

貌似全程没看到会被多个线程访问到的变量，所以是不存在线程安全问题
thenApply 是上一步执行完了执行下一步，是同步的，所以最后一个 thenApply 里能达到的 value 就是最新的
另外不存在 intA 比较旧的问题，intA 全程没有被重新赋值过，一直就是初始值

直接究极复古，复活塑料壳的型号吧
大铝坨太重了

“开启低电量模式以提高性能”

和手机前置摄像头一样属于用得少但是不能没有的东西
除非砍掉摄像头给便宜几百几千，要不没几个人会买，但是便宜那么多也没有厂商会做

cpu 性能可能连 m1 都打不过的大铝箱子，收藏还行，干活就算了
（难道楼主是来找人接盘的？……

就是拿来用的啊那么多内存
泄漏了或者抢内存太厉害了除非是

第一步，把“取 officeCode”抽出去，如果方法不是很多而且也不怎么调整，做到这里就可以了

private String getOfficeCode(BrChangedEvent e){
String code = findOfficeCodeByA(e);
if (!StringUtil.isEmpty(code)) {
return code;
}
// 后面的差不多
}

如果方法比较多且需要调整，那么就进一步抽

private List<Function<BrChangedEvent, String>> codeFinders;

{
codeFinders.add(this::findOfficeCodeByA);
codeFinders.add(this::findOfficeCodeByB);
codeFinders.add(this::findOfficeCodeByC);
}


private String getOfficeCode(BrChangedEvent e) {
for(Function<BrChangedEvent, String>> finder : codeFinders) {
String code = finder.apply(codeFinders);
if(!StringUtil.isEmpty(code)){
return code;
}
return null;
}
}

多个 cmd 键这个优势还是挺大的。。。

@unclemcz 水深火热就是这个作用

与往常一样，您的产品对我们的工作至关重要，因此请不要犹豫继续改进，给 JB 家足够的压力让我们能用到更好的 JBIDE 。

摸鱼码农，m1 用了快一年了，感觉已经赢了

@exploreexe 完全同意

共用的
需要多少内存，32g 内存够不够用，只有你自己知道
比如你现在 32g 完全够用那问题不大，否则就不够用呗