@uclort 上一代设计都 5 年了，是该变了，能加 HDMI 口应该是因为机身做直了，不是原来的圆角

@szDaoge 自己算没用，即便 965，差出来的 240-160=80 小时的时间，也没事干，也没有转变为收入的能力，最后还是会走回 996 的

我搞不清楚宕机是 hang 还是 crash

这事如果让别人知道，你会被抓去被迫去问某个问题

4S 店，图省事

电池保护的学习型充电模式吧？但你起早了？

你要真不懂，甚至都不会认识到自己被坑了，那不也挺好的吗，幸福

我给一个官方说法的指引吧： https://overreacted.io/a-complete-guide-to-useeffect/#speaking-of-race-conditions

副作用的清理和 rece condition 的应对是一个道理，都是 async 要在 effect 退出时中止（或至少告诉后续的副作用不要发生）

因为 React 的生命周期不是你控制的，严格来说是用户控制的（用户要离开你不能阻止他）
而对于 useEffect，在生命周期结束（或 deps 变化）时，副作用需要被清理
并且对于一个 async 的过程，如果它没有完成（未 resolve 也未 reject ），那么从理论上来说，在 effect 清理时它是**必须**被中断的，因为 async 过程完成后就会发生副作用，而此时 effect 已经结束了清理，这个副作用一但发生就会失控
所以，React 很简单地要求 useEffect 不能直接用 async 函数，来促使你处理 async 的中断逻辑

但很少有人理解到这个点，不但不处理 async 让异步过程随意泄露不可控，还怪 React 的 API 设计

直行掉头再回来，已经在实线区了的话就惨了……

docker 基本残废，其它都好

没有 CarPlay 的车永远不会在我的选购列表里就是了

还挺有艺术感的，留着当收藏品吧……

@Tink 原来的 url 能打开是 github 的功能

没事，我干过

21 款 BMW 430，确实是辆好车

@westoy echarts 一直是百度在维护，只是贡献给了 apache 而已，apache 哪来这么大团队维护所有基金会下的开源项目