首先，苹果电池健康度，跟常规的锂电池健康度，不是一回事。没人知道他是什么算法。然后，即时是常规锂电池健康度，也不是线性下降的，你甚至可以认为锂电池健康度只有还行、不行两个级别。

使用场景可以排除长期满电的不良影响。那就只剩锂电池寿命的终极原因了：大功率充放电。最后原因其实很简单：CarPlay 太耗电，导致即时插了充电线，电池还在高负荷运转。你以为插上充电线电池就去休息了，实际上并不是。充电为了稳定，电压和电流都受限，并不能 100%满足用电需求，所以即时是充电的时候，电池也要待命。如果你运行超耗电的 APP ，那么你会遇见这种情况：虽然插着充电线，但是一段时间后电池不但没涨反而掉没了。如果你运行耗电还不是那么猛的 APP ，那么变成这种情况：用电波峰期间电池放电，波谷期间电池充电——即电池在不停的大功率充放电。

@danhahaha #38 https://zh.wikipedia.org/wiki/Wikipedia:%E5%AD%97%E8%A9%9E%E8%BD%89%E6%8F%9B%E8%99%95%E7%90%86 抖机灵和秀智商，都不是好东西。

@enihcam #40 你英语起初是怎么学的。

Java 不适合单干。不要找大神，去找大的开源团队，你能找出来一大堆。找正式初版的技术书籍，你也能找出来不少。

离职证明跟赔偿是两码事，不需要走仲裁，直接找劳动局、街道办、派出所开都行。另一方面，按照现行劳动法，你把离职通知登报，1 个月后拿出来报纸截图，这就是 100%的离职证明。

至于社保、欠款什么的，碰见老赖你就真不用想了。但是该走的流程必须要走，问题必定要卡在对面老赖上，而不能是这边自愿放弃。

@enihcam #19 照你这思路，不如砍掉翻译这个行业，反正不管阅读对象动不动原文，你都只能看原文。

借楼上对 default 的溯源含义差不多就清楚了。「缺省」：在还没有合适意译的时候，用直译加技巧方式，生造的意译——可以看成是半直译半意译。「默认」：意译。

意译就不讨论了。关于「缺省」这种半直译半意译的方式，就有必要讨论一下。这种情况的根本原因是，对象语言中尚没有能贴切符合原语言的意译词，从而无法意译。当阅读对象是内部人员时，还可以选择不翻译，用术语解释来代替翻译。但当阅读对象是外部或公众人员的时候，是必须翻译的，如果不想音译，那就只能用直译，或者这种半直译半意译的方式。

「缺省」跟「默认」还引申出来另一种讨论：如果已经能意译了，那么临时的半直译半意译（也包含直译）的方式，是否还有存在的必要。这个就仁者见仁智者见智了。

要是没有那巨额的固定 IP 价格，还是真能相信运营商收回公网 IP 的原因是 IPv4 地址真不够了。

你大概不知道 windows 的输入法，技术上是通过入侵其他应用来实现的。输入法作为系统输入口，还是超高实时反馈的东西，它的权限必须是无法隔离的系统级别。如果你不是 100%信任输入法，就不要用，不要搞什么应用隔离。

现在 Google Play 、Apple Store 的部分应用都要手动禁止自动更新，你这国产应用还要紧跟更新，真是嫌死得不够快。

Android 常规应用更新，只能是 Google Play ，或者原厂特别仿 Google Play 的应用商店，因为只有他们才能拿到真正的应用管理权限。其他的，都要走黑科技，或者 adb 。

「 LaTeX ，是一种基于 TeX 的排版系统，由……利用这种格式系统的处理，即使用户没有排版和程序设计的知识也可以充分发挥由 TeX 所提供的强大功能，不必一一亲自去设计或校对，能在几天，甚至几小时内生成很多具有书籍质量的印刷品。……它非常适用于生成高印刷质量的科技和数学、物理文档。这个系统同样适用于生成从简单的信件到完整书籍的所有其他种类的文档。

LaTeX 遵循呈现与内容分离的设计理念，……而不必同时注视其外观。在准备 LaTeX 文档时，……它鼓励从内容中分离布局，同时仍然允许在需要时进行手动排版调整。这个概念类似于许多文字处理器允许全局定义整个文档的样式的机制，或使用层叠样式表来规定 HTML 的样式。LaTeX 系统是一种可以处理排版和渲染的标记语言 」

拿这玩意做笔记，你特娘的真是个天才。

如果是家里自己的网络，那就不用用默认的网络，那个其实不是 hyper 常规交换机，而是一个特殊的 NAT 交换机，一不小心就出问题，除了问题还没法调。自己手动建个「外部交换机」。

不管你是不是安全领域小白，最起码的基础尝试应该有吧。如果你找个人帮你读信，你觉得这个帮你读信的人有可能不知道信的内容吗？如果你找个人帮你理财，你觉得这个人有可能不控制你的钱吗？

@tnhmcm 关于 「 Thread.currentThread().interrupt() 」，更正如下。

此方式的设计理念是：当前代码选择直接吃掉 InterruptedException ，但是仍然设置中断信号，以不影响上层可能还有的中断响应。此时，如果上层没有中断响应，那么跟吃掉 InterruptedException 是一样的表现。但如果上层还有中断响应，那么怎么表现就取决于这个中断响应怎么做。

这个仍然是最后才选择的响应方式，首选响应方式，仍然是：如果该阻塞不允许被取消（譬如 sleep 被打断），就抛出业务异常；如果该阻塞允许被取消，那就按照取消去做后续处理，以你发出来这段代码为例子，它应该是清理 latch 并返回它的最新状态给上层调用代码，上层调用代码再自行判断是当成错误还是忽略。

Sonar 这个要求其实有点扯淡，它实际上要求必须按照正常情况去响应 InterruptedException 。但是有些场景，收到 InterruptedException 就是异常情况。场景举例，设计上就是要通过 sleep 来延迟 10 秒后再做后续处理，如果刚 5 秒就有沙雕打断它，那这就是异常情况，就该直接抛出去。

@tnhmcm #8 关于「 Thread.currentThread().interrupt() 」这块，我说错了，因为我把它当成 interrupted() 去看了，这块不要看了。

铁路旁边的没事，刚开始一个月会吵，后面就自动过滤了，而且是出去几年再回去都没影响的永久习惯。其实火车压铁轨的声音属于有规律的声音，不太算噪音。

货运车站旁边的就另说了。

需要提醒一下，sleep 的 InterruptedException ，你可能会搜索到让你用 「 Thread.currentThread().interrupt() 」来响应，这个是最后选择的响应手段，不要无脑用。它的实际效果，等同于空的 catch 。

以 sleep 来说，假如 sleep 10 秒，第 5 秒的时候 catch 了 InterruptedException ，如果你只做了 「 Thread.currentThread().interrupt() 」，那么最终的效果是：当前线程设计休眠 10 秒，第 5 秒的时候被其他线程给出了中断信号，当前线程以提前中止休眠（并继续后面的处理），作为中断的响应。

基本概念 1 ，线程阻塞状态，与同步任务的阻塞性，是两个概念：二者在某些情况下是相似的，但更可能是对立的；譬如，sleep 虽然阻塞当前线程，但减少系统整体上的任务阻塞性（如果当前线程不通过 sleep 、wait 等阻塞自己，那么他将一直占用 CPU ，导致系统整体上的无响应）

基本概念 2 ，中断不是中止：中断只是一个信号，表示请求提前中止；收到中断信号的一方，可以保存状态然后取消资源占用，也可以不予理会。

基本概念 3 ，中断与阻塞不是一个概念的两种叫法，相反，中断是用来取消阻塞的。



现在来看 InterruptedException ，它表示的是：正在阻塞的当前线程被其它线程打断（或者说，收到了其他线程发过来的中断请求，并且做了先期响应）；并不是，无法进入阻塞状态。拿 sleep 来说，抛出 InterruptedException 的过程是：已经开始休眠，在预期结束前收到了其他线程的中断信号，抛出 InterruptedException ，同时清除“中断”状态（抛出异常算是对中断信号的先期响应，自然也算是响应过了中断信号）。

InterruptedException 的本意是让当前线程响应中断信号。对于不允许取消的阻塞片段（通常 sleep 是如此的），处理方式应当是报错或者继续抛出。对于允许取消的阻塞片段（通常 wait 、await 是如此的），应当是取消后面依赖该阻塞的片段，例如死循环中可以通过 `continue` 来做取消。

你这个正好是 await ，这时候出现 InterruptedException 是正常的线程通信——根据场景推断，这有可能是外部发起了 cancel 动作，这时候你要做得是，取消后面的任务，然后通过 return 反馈任务已取消状态和任务实际执行的情况。不能通过 throw 来返回任务已取消，因为任务取消是不是异常，是由接受 return 的那一方决定的。当然，如果你的设定上是「任务不能被取消」，那么收到 InterruptedException ，也即取消信号，就可以抛出「不允许被取消的任务，被取消」异常。不过这个「任务不能被取消」的设定本身，可能就要挨批。

@Shura #5 A->B->C 构成供应链，给 A 投毒导致 B 、C 中毒，并还可能不断往后传播，这才是供应链投毒。商店上架个李鬼，哪来的供应链，那只是绕过了审核。