直接一个循环就搞定了啊，cd 不 cd 无所谓把？
把要检查的目录一行一个放在一个文本文件里，一个循环就好了，顺便把路径也会自动打出来：

#!/bin/bash

LIST=./list.txt

while read line; do
pushd ${line}
git status -s
popd
done < ${LIST}

chrome://flags/#unsafely-treat-insecure-origin-as-secure
看一下呢？

啊？不是附加调试器之后汇编代码单步跑吗？
没有源代码的话你怎么加 log ？

@asionbo 你域名都是 api ？
本地改 hosts，域名 api 指向本地 127.0.0.1，然后本地开个 nginx，/v1/ proxy 到远程，通过 IP 反向代理指定 host 头。/v3/ proxy 到本地服务。
除了 nginx，也可以用其他的 proxy 程序，比如 http-proxy

@1if5ty3
> B 化妆成 C，打了 A 一顿，那 A 在梦里是梦见 B 还是 C
我觉得应该是 A 会梦到 C，然后在梦里卸下 C 的伪装得知是 B 。

我觉得比较靠谱的是参考 windows 10 自带的那个 Sandbox 。

> 如果盲人能记住自己在地图的位置以及相对其他英雄的位置然后靠听比入攻击命中的音效
自己在地图上的位置也许可以记住，操作人物根据人物移速来判断人物实时位置。
但是敌人的位置怎么更新给你呢？毕竟不可能告诉你你的敌人正在做什么动作？

这玩意儿怎么感觉跟新版的 Twitter 那么像呢……

@VDimos 也许网关监测到了，但是报警系统出 bug 了。🐶

我觉得：Go 里的 if err != nil 判断是否出错，表明这里确实有可能出错，那么不论是什么编程语言，都是有可能出错的。
比如写个除法函数，返回商和余数，但如果除数参数提供了 0，那么结果就是应该出错（不考虑返回无穷之类的情况）。
在其他语言里，这叫“异常”，他们几乎都有 try-catch 语法，来捕获错误，比如：
```
try {
可能出错的函数 A();
可能出错的函数 B();
可能出错的函数 C();
} catch (错误 A) {
} catch (错误 B) {
} catch (错误 C) {
} finally {
}
```
在 Go 里面，实际上也有类似的写法：
```
defer func () {
if err := recover(); err != nil {
// 判读 err 的类型，处理不同错误
}
// finally
}()
可能出错的函数 A()
可能出错的函数 B()
可能出错的函数 C()
```
这样写是不是就有点类似了？
但是不管是 try-catch 还是 panic-recover，他们的问题都是：抛出错误，在某个位置集中捕获。这样在代码层面你就不知道错误具体是在哪里抛出来的了，只能在运行时打堆栈，相同类型的错误也就只能是统一的处理方法。

而 Go 语言的一般风格是：错误在哪里抛出，就在哪里处理掉，这样对错误的处理会比较明确。

比如在一个函数里有两个除法运算，除数都有可能为 0 。那么 try-catch 就只能在捕获到错误时打一个除数为 0 的日志，而 Go 的风格则可以报第一步除数为 0 或是第二步除数为 0 。

当然，try-catch 也可以写成 一行语句一个捕获的形式，那样的话比 if err != nil 更恐怖，而且还有变量块级作用域的问题。

@xuanbg 加密算法存在的后门我印象中之前看有文章说是：算法里面有一些莫名其妙的常数，这些常数是怎么选取的、为什么要取这个数都不清楚，所以怀疑是有后门，可以通过某些魔法数字直接绕过算法进行解密。
好像后面看哪个算法的优点里也提到了这一点，说里面取的所有常数的来源都是明确的。
具体细节不记得了。

OpenStreetMap （ OSM ）自己下载全球（或是指定区域）地图数据，根据自己的需要渲染地图，自己假设地图瓦片服务器。
配合 Leaflet 地图库，几乎可以涵盖高德百度地图的所有功能。

这一套完全可以离线部署。

另外关于 OSM 自己下载数据渲染这一步，如果觉得麻烦的话，可以写个爬虫，直接去爬 geoq 或是 wikimedia 的瓦片图，下载下来自己搭个静态文件服务就行了。

我觉得只是风格不一样。
第一种要记得加 !!，控制显示与否的时候用。
第二种在条件显示两种不同东西的时候用，return flag ? <A /> : <B />;

GitLab 上也有人备份了： https://gitlab.com/ytdl-org/youtube-dl
相比 Gitee 上的备份版本少了最新的一次提交

@ysc3839
> 除了 Windows，一些 Linux 的桌面环境，以及 Android 、macOS 也会通过文件后缀来区分文件类型，不见得所有类 Unix 系统都是通过读取文件内容来区分文件类型的。
这句不对，这些系统并不是根据后缀拓展名来区分文件类型的，而是根据扩展名来决定 [使用什么程序来处理这个文件] ，相当于给文件进行一个不强制的分类而已。比如看到 .aaa 后缀就交给 A 程序处理，看到 .bbb 后缀就交给 B 程序处理。
windows 下也是如此，正如 @AX5N #17 #18 说的那样，这类知识没人教，所以很多人认为 Windows 下是通过扩展名来识别文件类型的。其实不是，Windows 也仅仅是根据扩展名来决定使用哪个程序来处理这类文件而已。

> 而且读取文件内容来区分文件类型并不是一个很好的设计。
是不是一个好的设计我不知道，但至少现在几乎所有程序都是根据文件内容来区分文件类型的，区分的方法是判断“文件头”，也就是文件开头的几个字节是什么。
而通过文件扩展名来识别文件类型却并不可靠，比如 @em70 #19 说的早期 PS 如果图片扩展名不对就打不开。并且现在网上有好多的图片文件扩展名也都不对，网络上一般通过 Content-Type 中的 MIME 信息来标识文件的处理方式，比如是图片还是视频，还是要求下载。所以网络上的图片很大一部分都是没有扩展名的，这就导致你右键另存为之后文件没有后缀而打不开。
（当然，这里很多人会不管图片具体是什么格式而直接将扩展名改成 .jpg 或者 .png ，告诉系统这是张图片，用图片查看器打开就行，图片查看器通常不会管你的拓展名是啥，而是根据文件内容的前几个字节来判断文件类型进行解析渲染）

跟 HttpOnly 有什么关系？ HttpOnly 的 cookie 在 Websocket 连接的时候也是会正常发送的啊！
刚刚在 Chrome 和 Firefox 下测试没有问题，标记为 HttpOnly 的 Cookie 在 Websocket 握手的时候都可以正常发送。

网上搜了一下，只有 2010 年 1 月苹果的 Webkit 存在 bug 导致 HttpOnly Cookie 在 WebSocket 下不发送，但是也早已修复： https://bugs.webkit.org/show_bug.cgi?id=34289

另外搜到一个 UC 浏览器同样的问题： https://stackoverflow.com/questions/43224033/uc-browser-not-sending-httponly-cookie-for-websocket-calls 估计也是用了那个有问题的版本的 Webkit 内核代码。
如果确实要考虑这些使用旧版带 bug 的浏览器的用户，这个问题下也给出了参考方案：在 WebSocket 连接建立之后，若用户没有携带 Cookie，则在 Websocket 中给用户一个唯一 ID，用户拿到 ID 之后通过正常的 HTTP 带上 Cookie 请求一个 API，这样就可以将这个 Websocket 连接的 ID 与用户的 Cookie 进行绑定。加个超时自动断开连接就行。

角度=弧度*180/π

不需要路由器透明 XX，直接本地跑个透明 XX 就行