既然没有人贴代码，我就先抛砖引玉了。19 MB，二分查找。

https://gist.github.com/lujjjh/fecf55f6827cce011bb71682e9b8594a

更正 [md5(s), int] → [(md5(s), int)]，或者写成 list<(md5(s), int)>

看要根据 key 查 value，还是需要遍历，如果只需要根据 key 查 value：
1. 用 md5(s) 代替 s，碰撞理论上可忽略，64 bytes → 16 bytes (binary)
2. map<md5(s), int> 变成 [md5(s), int]，按照 md5(s) 排序，100 万条数据二分查找 20 次以内

@ifwangs
@Maskeney
刚才 smtp.qq.com 的证书确实也有问题，现在测了下 imap.qq.com 和 smtp.qq.com 证书都已经更新了。

然而 imap.exmail.qq.com 和 smtp.exmail.qq.com 的证书还是有问题，如果有腾讯的小伙伴请帮忙反馈一下。

只能说这个设计思维清奇，把当前浏览的 cam id （姑且这么叫了）存到 session 里。或者说服务器端有一个 [session id] => cam id 的映射关系。

请求 m3u8 的时候通过 query string 把 session id 传过去，服务器端再找到这个 session id 映射的 cam id 。

并不会增加爬虫的难度，但是限制了一个 session id 只能同时观看一个 cam 。

PAC 只是决定要用什么代理，具体要看使用的代理方式是否支持使用域名。

举个例子，SOCKS4 因为协议设计的原因只支持 IPv4，而 SOCKS5 或者 HTTP 还支持域名和 IPv6 。

@hxse 这首歌确实是炫技，多曲风，主歌很多歌词也都在解释音乐，比如「几个高级和弦，几个切分音」、「换个乐器就像换个兵器」、「电吉它这个时候出来干嘛 到底」都能跟音乐对上。

@Raven316 只是觉得你以专辑里博传唱度的歌评价音乐性并不客观。编曲上看，《土耳其冰淇淋》绝对算得上是风格上的突破。

「我干脆自己下车，指挥乐坛的交通」──《告白气球》同张专辑的《土耳其冰淇淋》

https://blog.golang.org/error-handling-and-go

其实你要判断的是 err 是不是 Temporary 的，如果是，就是 retryable 的。

> 直接用 Java 写然后编译成 JavaScript 不好么

同样可以说，用 CoffeeScript 为什么不直接写 Python 然后转义成 JavaScript ？

只能说，有很大一部分人确实有类型系统的需求，主要原因当然还是前端工程化的发展。简单来说就是确实需要一种类似 Java / C# 的前端工程化语言，但又不那么 Java / C#。

事实上，近几年来人们对创造新语言越来越克制了，会考虑这个特性是不是值得造一门语言通过语法层面解决（除了 CoffeeScript，再想想 pug 、sass 、less ）？同样，随着 ECMAScript 本身的发展，CoffeeScript 在语法层面的优势是不是依旧得以超过引入一门新语言可能带来的生态问题──比如 CoffeeScript 2 还是有一些 breaking changes 的，但是如果不升级是不是就没法用 async functions 和 JSX ？

相比而言，TypeScript 的定位是 JavaScript 的超集，语法上没有那么激进，解决的问题也足够实际。我觉得这是 TypeScript 更容易被接受的原因。

我的观点是，如果没有遇到需要使用 TypeScript 的场景，确实也没必要强上，但是在 TypeScript 有明显优势的场景，不用白不用。更重要的是对新技术有包容的态度，即便我写了十几年 JavaScript，不理解新技术有什么用，但也不排斥，相反我会充满好奇上手试一下。

不管是 JavaScript 、CoffeeScript 、TypeScript，甚至 ClojureScript，只要场景合适我都用──JavaScript 写一些小 demo 很快，不需要任何构建系统； CoffeeScript 写 parser prototype，可以充分利用语法上的优势，而且本身就是一个比较 geek 的场景； TypeScript 写工程化的项目和服务端应用。

目的：在任意 app 界面查看负一屏，然后返回 app 界面。

操作：
1. 在任意 app 界面，顶部下拉打开通知中心，此时右滑可以打开负一屏。（译者注：我从来没有这么用过）
2. 想要回到 app 界面，需要执行逆操作：左滑返回通知中心，然后再从底部上滑。

问题：iOS 14.5 之后，第 2 步会错误地打开控制中心。

解决方案：左滑返回通知中心后，按 Home 键代替从底部上滑。

结论：iOS 14.5 进一步恶心了 Home 键 iPhone 用户。（来自标题）

调 EQ 一定程度上可以弥补差异，有个做 audio matching & mastering 的项目可以试试看效果如何 https://github.com/sergree/matchering

在写 GUI app 的时候都会注意不要 block 主线程，不然会导致 event loop block 住，整个 UI 就卡死了。你说的其实也是这个意思。

node.js 和 Python 里基于绿色线程的各种框架，event handler 不会跑在单独的线程 / 进程里，所以一旦业务函数 block 住，其他请求就进不来了。

node.js 相对 Python + gevent 来说心智负担小很多，对于会 block 住 I/O 的函数，标准库里基本会标明 xxxSync 。然而并没有办法阻止其他人或者直接 /间接依赖使用 xxxSync，除非 review 包括依赖在内的所有代码。所以我倾向于这个问题是没法完全避免的。

那怎么办？其实不必过于担心这个问题，一般写业务，能产生 I/O 的地方也就那么几种类型，选择好对应的库就可以了。对于其他场景，比如写基础设施（写基础设施真的会用 Python 么？），code review 能杜绝大多数问题，主要看能产生 I/O 的地方。剩下的就交给压测了，这种明显会产生性能瓶颈的地方绝对是可以压出问题来的。

这个好像只能在打开开发者工具的时候奏效，关闭开发者工具之后强刷页面，就没了。

@Girlphobia 「使用自定义 CSS 」功能的痛点是插入的 <style> 在内容之后，内容显示出来了才会加载自定义样式，视觉上会闪一下。

看来还是得使用插件……

比较好奇，现在在个人网站上放视频，需要申请网络视听许可证么？（好像个人也搞不了这个许可证）

@no1xsyzy 怎么感觉你对 js 这么恨铁不成钢[doge]。jsx 至少还算是 opt-in 的。

无意引起争论，给 ECMAScript 提 proposal 或者发明一种新语言都没啥问题。只不过在 #16 给出了点基于 js 扩展要考虑的问题和建议而已。至于后面那段实现很脏的代码，也是在跟 @Jirajine #18 探讨 js 实现类似 DSL 的可能性。

既然又回复了，我就再给这个「在 JavaScript 中使用 Swift 的尾闭包语法」的项目提点建议（如果楼主的本意是设计一门全新的语言请无视）：

* { b, c in ... } 这种语法毕竟是 Swift 的闭包语法，基于 js 扩展用类似 arrow function 的语法更具一致性。
* 可以在 babel 的基础上魔改，再写个插件，就可以在实际项目中使用了。

最后也分享个我搞的语言，欢迎交流： https://github.com/lujjjh/gates

@no1xsyzy Talk is cheap，我的核心观点还是在 #16 。像 Svelte 那样动编译器跟动语法是两码事，动语法带来的问题太多了，工具链是问题，方言能不能被大众接受也是问题。React Hooks 实现得这么黑本质上也是为了在 js 的限制下设计出一套相对好用的 DSL，否则完全可以设计成 Vue Composition API 的样子，改动语法可能性就更多了。

@no1xsyzy 你可能没有看全上下文。我当然知道 closure 返回数组的话很容易处理。

我思考的问题是怎么避免手写数组，或者说怎么模拟 Swift 的 function builders，从而实现一个更简洁的 HTML DSL 。js 里引入全局的存储应该是唯一解。

你可以看到我的代码里 L23-L28 在使用的时候完全没有手写数组。