需要提醒一下，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 中毒，并还可能不断往后传播，这才是供应链投毒。商店上架个李鬼，哪来的供应链，那只是绕过了审核。

看了半天，也没发现供应链投毒在哪里，只看到了冒牌应用，而冒牌应用被大量下载的主因还是百度。

合同，职工手册，或者其他明确的书面规定，有明文说明年终奖吗。有就仲裁，没有就别想了。

@cslive #6 再补充一个，是 https://addons.mozilla.org/zh-CN/firefox/addon/ublock-origin/ 这个 URL ，即扩展的描述/入口页面，做了 IP 针对。但是，扩展本身的下载地址，没做针对，那个大概率是动态地址，也没法做 IP 针对。

@cslive #6 扩展商店本身针对大陆 IP 的区里，只有这么一个处理。所以你用那个版本都会被屏蔽。但同时，你用那个版本，都不影响你通过帐号同步扩展。

https://github.com/gorhill/uBlock/releases 。找最新的 uBlock*.firefox.signed.xpi ，这个其实就是扩展商店上的历史版本。如果是不带 signed 的 uBlock*.firefox.xpi ，这个默认的 Firefox 是安装不了的。

去 github 下安装包，要下 firefox signed 的那些。

现代人是有多断代，睡前不能喝（茶叶）茶/咖啡都不知道。

当你把茶跟水做比较的时候，那就不能只说茶叶茶，要说广义上的茶。开水里面泡了点东西的都叫做茶，比如菊花茶、大麦茶，枸杞泡水本质上也是枸杞茶。即时是茶叶茶，也有基本上跟树叶没啥区别的碎末茶。

如果单纯从技术层面讲：
问题 1 ，前后端谁做都可以，后端的视图层，前端的 Model 层都是干这事的，至于具体谁做，首先要看以前谁做，其次要看现在谁愿意做，最后才是看谁有时间做。
问题 2 ，不与代码同步的文档不如没有文档，没有管理的编码不如直接用名称。尤其是经过大数据分析的发展之后，那种没用的编码，还是让他步入坟墓吧。

实际上你不要扣技术，没意义。

实体关联，不管你是数据库层面的物理外键，还是程序层面的逻辑外键，都要用物理主键，否则你也没必要再在自然键之外设计一个代理主键。

对于你的 stock_in 来说，用 material_id 做关联键，才能发挥代理主键的性能。mateiral_code 也有用，但它更多的是作为 stock_in 自身的属性来用。

@luodaoyi #4 内网直连的前提，是（端对端）直连，你觉得国内敢有端对端直连的需求——parsec 这个单纯的串流工具，那可是上墙的。

在还不熟悉 git 工作流的时候，先强制禁用默认的 merge pull （ fetch + merge ），改为 rebase pull （ fetch + rebase ），这样的话，提交历史的表现会跟 svn update 一样的。

@foufoufm #12 你有一个互联网人非常容易犯的错误——一边认为互联网再创造东西，一边价值观还停留在自给自足上。无货源电商，跟卖可口可乐的小吃店，在市场表现上就是一样的。

你再好好想想，那是回访，还是推销。

你把它看成批发零售就行了。其实实体商业上的批发零售，有不少行业，比如可口可乐，零售端也是不管货的。香烟虽然要进货，但不想卖/卖不出去的时候时能 100%原价退回去的，也可以认作是无货源的。

软件领域的绝大部分造词，只要它是真得用来解决问题的，那就没必要关注优缺点，只要它被拿到了推广人/公司的文章上，那它就只有缺点。

你现在回头去翻翻 Java 的发展史，那些用过但消失的东西，EJB 、Struts 、J2EE ，你会关心他们的优缺点吗，它们只不过是某一段时间真能解决问题，然后又自然被淘汰。