分成两组 1-4 。

每组 4 瓶编号 1-4 。

用三只，

一只喝 1,3，一只喝 2,3，一只喝 1,2 。

另外一组分别喝，1,3 2,3 和 4 。

A: 13 和 23 死掉的情况，看另一只喝 1,2，死了，1 和 2 都有毒。没死，3 确定有毒，4 可能有毒看下一组情况。
B: 13 死了，23 没死，1 有毒，4 可能有毒看下一组情况。
C: 13 没死，23 死了，2 有毒，4 可能有毒看下一组情况。
D: 13 和 23 都没死，4 可能有毒看下一组情况。

此时看另一组：

A1: 13 和 23 死掉的情况，4 死了，3 和 4 有毒，4 没死，3 和上一组 4 有毒。
B1: 13 死掉了，23 没死，4 死了，14 有毒，4 没死，1 和上一组 4 有毒。
C1: 13 没死，23 死了，24 或者 2 和上一组 4 。
D1: 13 和 23 都没死，4 死了，4 和上组死掉的那个没死就是上组 4，4 没死，把上组的`可能`换成`肯定`。

个人理解= =。

异步模式不是把同步的代码异步化，而是那段代码本身就是一个异步的 IO 。

想把一段代码异步化，得先知道这段代码能不能异步，比如

```
a += 1
```

是一段不能异步的代码。

而一个网络请求则一般都会提供 阻塞和非阻塞 两种模式：

```
http({
async: true(false)
})
```
这样的配合事件循环就可以做到异步。

在 Python 中，像是`requests`是一个阻塞的网络请求，它并没有提供非阻塞的参数，无法直接用类似线程的`async(requests.get, xxxx)`这样的方式去将它异步化，而是应该在底层 socket 建立连接时就使用非阻塞的模式，交由异步的事件循环在这条 socket 等待响应的这段时间去干别的事。

按楼主的举例，commands 是一个阻塞的命令行，确实想用异步应该寻找的是一个非阻塞的命令行而不是想着有一个函数可以把 commands 异步化(事实上 Python 也有，`asyncio.base_event.run_in_executor`函数可以让传入的同步函数放在一个线程 /进程池中执行，同时外部还可以继续用异步的 async/await 或者回调)。

而在 Js 中，如果你在主线程中执行一段一直会占用 CPU 的代码(while(1){})也会阻塞住整个页面。

异步主要是用来解决 I/O 密集的问题的，I/O 所花的时间主要在网络读写，硬盘读写等。

如果一段代码的主要消耗的是 CPU，用异步并不是一个好选择而是应该尽可能榨干 CPU 的性能，衍生出来的就是线程(协程)/进程。

所以在 Python 这个啥程都有的语言里...

在主要是 I/O 的场景里，用非阻塞的库上异步绝对是一个性价比高的选项，其他程切换的开销再小也有开销。
在主要是计算的场景里，多跑几个 Python 进程比啥都管用。

访问量不大的网站用什么根本无所谓...数据量够小的情况下，选择排序和快排根本看不出差别。

React 版的源码是打包后的？一个上传失误？

项目只有前端内容，没有与后端交互的内容，还是有一个比较好。

画龙猫的项目挺有趣。

记账的项目有点简陋= =...

还有一个思路是用 SSR，Nuxt 里写 layout，这样就可以完全使用 Vue 的生命周期。

荆棘。

谐音：镜姬，痒痒鼠反弹伤害的装备。
谐音：军纪。

~

```
function parse(res) {
a = Promise.resolve(res)

const then = function (func, rej) {
if (!rej) {
rej = () => {
console.log(1);
alert(1);
}
}

a = a.then((res) => {
return new Promise((resolve, reject) => {
try {
resolve(func(res))
} catch(e) {
reject('err')
}
})
}).catch(rej)

return thenObj
}

const thenObj = {
then: then
}

return thenObj
}


parse({test: 'test'}).then((item) => {
console.log(item)

return item
}).then((item) => {
console.log(item)
throw 'error'
})
```

可以封装一下 `.then`。

```
const list = document.querySelectorAll("li")
for (let i of list) {
i.addEventListener(...)
}
```
这个有啥不好吗，除了没限定 ul?

当然也可以给 ul 加事件判断冒泡的发起元素，这样只需要监听一次点击事件。

递归最大的缺点是不是性能不高？

Vscode 丢 Github= =..

`import T-Shirt`

当看到“孩怕”时我略有疑惑很快就懂了，但是我看到“鸭鸭走”和“开始门”的时候只有？？？和？？？= =。

@xuegy

好吧~，have a good day~.

@cyrbuzz
vscode，单行开正则...

(.+) (.+) = (.+);
$1 $2($3);

比格沃斯。

solarized light 真香。

https://github.com/HuberTRoy/myown/blob/master/%E5%9F%BA%E4%BA%8E%E6%80%9D%E8%80%83%E6%89%80%E5%81%9A%E7%9A%84%E6%8E%A2%E7%B4%A2/%E6%80%A7%E8%83%BD%E6%96%B9%E9%9D%A2%E7%9A%84%E6%8E%A2%E7%B4%A2.md

https://github.com/HuberTRoy/myown/blob/master/web%E7%A8%8B%E5%BA%8F%E4%BC%98%E5%8C%96%E6%80%9D%E8%B7%AF.pdf

优化公司产品时的总结，lighthouse 从不到 10 分已经提升到了 50~60+。

我自己的实践优化方面是：
1. 第三方资源非阻塞加载，async/defer 标记，这个提速很大。
2. DNS/CDN(百度统计等)链接的预查询与预连接，这个看不出来效果，提速微小。
3. 服务器端支持 HTTP2，比 HTTP1.1 快了不是一点两点。
4. 利用服务器端进行延迟加载，本身是个 Nuxt 的服务器端项目，利用 client-only 标签配合 import() + v-if 条件渲染，其实就是个分块+懒加载不过效果巨大，鹅且平时写组件的时候几乎都用 import 静态导入，调用频率低的模块也可以用 import()来改写。
5. webpack 打包时的 tree-shaking，老生常谈的 lodash 和 lodash-es 等等，这个减少的是传输体积，如果项目本身冗长这块提升也非常大。
6. 缓存这个就不用说了，检查检查有没有配置合理。
7. 图片移动端剪裁成 2 倍实际显示大小的尺寸，PC 端 1 倍，牺牲小部分清晰度的同时大幅减少传输体积。
8. 项目具体内部的代码优化，比如之前实现了一个利用 vue computed 属性的动态设置 style 的滚动效果，发现占用 CPU 20%以上....然后改成了 animation 。