@daoqiongsi1101 所以啊，你只要想一想，你 10 个 goroutine 请求是同时请求的，还是有先后顺序的？肯定是同时的啊。

实际上，同时并发请求数受到操作系统的限制（端口数、ulimit 、maxfiles 之类的），为了避免达到操作系统限制，同时降低建立 TCP 的开销，所以浏览器才会实现较小的并发限制。
实际上，具体是看你 golang 代码怎么写的。多个 goroutine 是用的同一个 http.Client 还是不同的，单域名连接数配置的多少。
如果是使用默认的 http.Client 来请求的话，那么走的就是默认的 http.Transport 配置，里面指定的单域名连接数 MaxConnsPerHost 默认是 0 ，也就是不限制。那么你只要没有达到操作系统限制，并发就是能建立多少 TCP 就建立多少 TCP 来并发请求，所以 10 个 goroutine 就是 10 个 TCP 。
而另外，可以针对单个 http.Client 对象来限制连接数，那么使用同一个实例来请求就会受到限制，达到限制就会阻塞等待。

另外注意，这个连接数跟连接池关系不大。默认的 http.Transport 的连接池有两个配置：全部连接池大小 MaxIdleConns 默认是 100 、单域名连接池大小 DefaultMaxIdleConnsPerHost 默认是 2 。这两个配置不影响并发请求的 TCP 连接数。

假设现在是单域名，单域名连接池大小 DefaultMaxIdleConnsPerHost 是 2 ，MaxConnsPerHost 并发数设置了 5 。那么此时你开了 10 个 goroutine 并发，并且每个请求都是 1 秒响应，则会发生这样的情况（实际情况可能受各种竞争因素影响）：
1 ，建立 5 个 TCP 连接并发，剩余 5 个连接阻塞等待。
2 ，5 个连接请求结束，只有 2 个 TCP 连接进入连接池复用，剩余 3 个 TCP 连接被 close 。
3 ，剩下的 5 个连接开始请求，其中 2 个复用之前连接池中的 TCP 连接，另外 3 个则建立新的 TCP 连接进行请求。
4 ，所有请求都结束，连接池中持有 2 个连接等待复用，其余连接都被 close 。
5 ，如果没有更多请求了，则连接池中的连接在超时（ IdleConnTimeout ）后被自动 close 。或者等待 TCP 自己的 keepalive 超时规则（ tcp_keepalive_time 、tcp_keepalive_intvl 、tcp_keepalive_probes ）来关闭连接。

等下，HTTP/1.1 的请求，并行不是复用同一个 TCP 啊？串行才是复用同一个 TCP 的啊！队头阻塞也是复用同一个 TCP 连接的串行 HTTP ，后面的请求要等待前面的请求响应啊。
Chrome 并发连接数限制是指创建的 TCP 的连接数啊，并且仅限 HTTP/1 。

HTTP/1 还没有分帧并发的技术，所有数据都是串行发送的，不存在你说的“并发请求、顺序响应”。要实现并发，就得建立多条 TCP ，在多个 TCP 连接上同时请求。
HTTP/1 的 keep-alive 是指一轮 请求-响应 结束后，不关闭 TCP 连接，可以直接在当前 TCP 连接上进行新的 HTTP 请求-响应。

本地启个 v2ray 后台进程，出口自己配路由指定不同域名走不同代理，或者不走代理。然后 Chrome 启动直接全局代理 127.0.0.1

@markgor 并发数限制在 HTTP/2 下不一样了。
HTTP/1 下限制连接数是因为 HTTP/1 的特性，单个连接上只能串行传输，要并行传输就得要建立多个 HTTP/TCP 连接，而这个连接是有开销的，并且操作系统对这个也有上限，所以浏览器实现的时候就需要限制连接数。
但 HTTP/2 不一样了，浏览器针对一个主机始终只建立一个 TCP 连接，在这一个连接上进行多路复用并行传输 HTTP ，所以并发数理论上是无限的了。实际上浏览器端和服务端可以通过 HTTP/2 的 SETTINGS_MAX_CONCURRENT_STREAMS 配置来协商并发数限制。

@pcell excel 也存在问题，但是现在比较新的版本都做了近似补偿： https://docs.microsoft.com/en-us/office/troubleshoot/excel/floating-point-arithmetic-inaccurate-result
比如输入公式：=1.333+1.225-1.333-1.225 可以得到 0 ，但是输入 =(1.333+1.225-1.333-1.225) 就得到了 -2.22045E-16

@knowckx #18： https://go.dev/blog/constants#numbers 所有纯数字表达式（包括四则运算的结果、复数等）都是常量，会在编译时给你替换好。

经过测试，应该确定确实是 iOS Safari 的 bug ，应该是 safari 在做优化的时候，只考虑了 translate 而忘记考虑 scale 的影响了，具体现象：
你同时为图片增加了 translateX 和 scale ，图片原本宽度为 620px ，它发现你 translateX(-1000px) 之后，图片应该已经在可见范围之外了，并且动画运动到 translateX(-1100px) 全程都应该在可见范围之外，所以直接将动画“优化”掉不执行了，反正效果就是元素在原来的位置消失，在动画结束之后再在新位置显示出来，那就直接不计算动画了，直接“跳刀 blink”即可。
但是它没料到实际上你同时为图片增加了 scale(2.5)，把图片放大了，此时图片宽度变成了 1550px ，动画全程都在可见范围之内了，导致这个“优化”露馅了。

按照这个理论，你将动画改为从 translateX(620px) 变化到 translateX(621px) 就会触发 bug ，但是只要某一个值小于 620px （图片原始宽度），bug 就不会复现。

@Mutoo #3 给出的用 matrix 的解决方案，应该是绕过了这个 bug ，将 translateX 和 scale 的结果融合进同一个矩阵，Safari 就会考虑完整的变换结果之后再进行动画的优化。

应该可以给 webkit 提 issue 了。

所以……为啥日常要用 root 身份……

你的消息队列里存的是消息通知，而不是消息内容？？
用到消息队列，应该是缓解数据库那边的压力吧？如果你的消息可以直接入数据库，那应该没必要用消息队列了？新消息来了先写数据库，然后判断用户是否在线，在线的话就推一条新消息通知，用户阅读的时候再查数据库获取数据。
如果消息量比较大的话，就先把消息放到消息队列，消息入队的时候不通知用户，队列直接输出对接到数据库入库。写完数据库再判断用户是否在线，在线推送。

至于轮询和 websocket 的选择，看具体的业务实时性：1 、实时性要求非常低，那么完全可以不推送，用户刷新的时候获取新消息（ V2EX 貌似就是这个模式），2 、web app ，用户很少会刷新页面，而实时性要求不高的话，用轮询 30 秒、1 分钟，3 、要求实时性高的场景，则使用 websocket ，几乎是实时的。
轮询需要接口能够承受住刷新请求，websocket 需要服务端能够持有足够多的 socket 连接。
至于 #6 的 push 消息，使用场景不太一样，主要用于用户没有访问你的网站时也可以收到通知推送（类似于手机 APP 的后台被杀掉，也还是可以通过 FCM/APNs 收到实时推送消息）。你需要注册一个 service worker ，然后用户不需要打开你的网站也可以收到消息推送（只要浏览器在运行，sw 就能在后台接收消息推送），消息推送的形式是通过浏览器的 notification 弹窗（用户必须先授权弹窗）。

@Newyorkcity #26 滑动输入就是输入的时候，手指完全不离开屏幕，在键盘上连线，把拼音字母按顺序连起来。
比如全键盘下要输入“你好”，就在 n 上按下，然后依次滑动到 i 、h 、a 、o 上，然后松开，不用特别精确，中间经过的其他按钮无所谓。9 键也是类似，在 6 上按下，然后依次滑动到 4 、2 、6 上，然后松开。
用习惯的话打字会更快。
目前我只知道 Google 的 Gboard 键盘是支持的，iOS 和 Android 都支持。iOS 自带的貌似只有新版系统的英文全键盘支持。其他输入法没用过不知道。

感觉这个 14 键理论上也是能支持的（毕竟 Gboard 的 9 键都能支持），就看具体使用的输入法有没有这个功能了。

Type-C 算 USB 吗？那 Type-A 呢？

@solitude3985 我可能是经历过输入法的历史，所以觉得目前这样的设计没什么问题？
首先是键盘的问题，不同的语言不同的键盘，这个很好理解，输入中文就用中文键盘，输入英文就用英文键盘，输入西班牙文就用西班牙键盘。
然后是中文键盘可以输入英文的问题，这个的确如楼上所说是个 feature ，因为在中文环境中出现英文是完全正常的情况，中英混排是属于很常见的需求，并且在特定情况下，使用纯英文的内容也是很常见的（比如很多广告牌、公告标识都要中英文双语），当然也有用拼音代替英语的。可以说国内经过这么多年从小学开始的英文培训，英文在国内也算是较为通用的语言了。所以在中文输入法中能够临时切换到英文输入状态，不觉得很“理所应当”吗？
印象中很久以前，智能 ABC 的年代，貌似是不能输入英文的，那么要临时输入英文单词、句子、拼音标注，就必须要按快捷键切换输入法，如果系统中有多个输入法（双拼、全拼、五笔，甚至还有区位）就得切换好多轮，因为当年电脑都是共享的，一台电脑一群人用，所以存在多个不同的中文输入法适应不同人的习惯需求是很常见的。还记得以前要切换到英文输入法，按快捷键 3 次，再切换回中文全拼输入法，再按快捷键 2 次，如果不小心按多了，那再多按 4 次……如果系统中的输入法更多（比如还要输入其他语言什么的），就要切换更多次数。

最后，回到你的问题，为啥会有这么多种组合。
首先是键盘语言，因为要适应不同国家的特点，所以出了不同语言的键盘分类。那么在中国就是用中文键盘，你单独添加一个英文的键盘算是一个“满足需求，但非预先设计”的方案，为了个人需求，你也可以添加西班牙键盘、日语键盘等。
选择了键盘语言之后，就要选择具体键盘（输入法）了，不同语言下会根据这个语言的特点推荐不同的输入法，但由于英文算是全球通用，所以也会有纯英文输入法。然后在中文输入法中切换英文输入是特定 feature 。
所以这个设计是比较明确的：语言>输入法>功能，不同语言、不同输入法下面的功能可能会有重合。

注：即便如此，也推荐为英文输入使用 英语（美国）的 QWERTY 键盘，因为部分游戏会假定这个键盘，如果你没有使用这个键盘的话，就会强行给你临时增加这个键盘（重启系统后消失）。但这个应该跟微软没关系，是游戏的问题……

@pilipili 貌似说的不是以前的卡饭论坛，是一个单独的 SEO 采集站……

我觉得熟悉这个 14 键，难度和全键盘差不多，因为键位基本上是完全一样的，都是 QWERTY 的键盘。但和 9 键差的太多……因为 9 键的键位完全不一样，属于 ABCDEF （但又和全键盘的 ABCDEF 完全不一样），9 键完全是靠着“熟能生巧”来打的……
我这种中文只用 9 键，用不惯全键盘的，因为全键盘按钮太小容易误触，另外也是很难适应用拇指去按这种 PC 键盘的布局。
用 9 键，完全是因为上古时代还没有触屏的年代，手机键盘大多数都是 9 键的，打习惯了就会了。而如果习惯了 9 键的情况下，9 键的按钮更大，不容易误触……
但如果是对 9 键没有历史习惯包袱，或者用惯了 PC 的全键盘的话，适应这种 14 键可能会快一些……

对楼上几个回答做个简单补充：
注：下面提到的安全性都是假设 CAS 服务是安全的，而下面单个 App 可能存在安全漏洞。而降低安全维护成本是指，你只需要重点考虑 CAS 的安全性即可将风险降到最低，漏洞影响不至于扩散到所有业务（但并不是说下属 App 的漏洞就不需要补了）

@ZSeptember #3 没有提到从 CAS 带回 App 的 cookie 应当如何验证，存在两个问题：
1. 从安全的角度来说，不应当携带 CAS 的 cookie 回到 App ，因为这个 cookie 一旦泄漏，影响将会直接扩散到整个 CAS 下接入的所有服务，一个 cookie 就可以走遍所有服务了。这增大了安全维护成本，任何一个 App 存在安全漏洞，都会扩大影响到所有其他 App 。
2. 每个接入的 App 都要对 CAS 的 cookie 信息做兼容，App 后台需要同步存储对应的 cookie key 信息，或者统一向 CAS 请求验证增大单点服务的带宽压力。而如果采用类似 JWT 的方式， 这种方式不仅存在天生的设计缺陷（不支持注销强制过期、续期需要跳回 CAS 来进行等），还需要在每个接入的 App 后台存储 secret key ，和上面一条类似，增大了安全维护成本，一个 App 存在漏洞泄漏了 key ，会直接影响所有 App ；并且要更新 key 也需要统一通知所有接入的 App 进行升级，这个成本太大。

@InDom #7 提到了 cookie 的安全性问题，并做了改进。但是还是存在一些问题：
1. 采用将用户名加密或签名带过去的方式，也存在问题，同样也是安全维护成本的问题。如果一个 App 存在安全漏洞，那么当用户登录这个 App 的时候，攻击者就可以立即获取带过来的加密或签名过的用户名，使用这个数据就可以立即解锁所有 App （因为的确是 CAS 进行的加密／签名操作，所以肯定是合法的）。
2. 使用 JWT （就是做签名）意义不大，即便 JWT 存在过期机制（就是同时签名了个时间戳），但攻击者通常都是使用脚本进行攻击的，拿到 JWT 之后瞬间就可以解锁所有服务，JWT 过期时间定多久都不合适。
3. 使用 Ajax 不可取。CAS 与 App 的域名肯定不同，这就属于跨域请求了，那么 CAS 的登录 cookie 就属于第三方 cookie 了。目前浏览器在逐步将 cookie 的 SameSite 属性默认值改为 Lax ，也就是不发送第三方 cookie ，那么 CAS 在 Ajax 的情况下永远都是返回未登录。除非你已经部署 https 并且主动在 CAS 上将 cookie 的 SameSite 属性设置为 None ，但这样就会引发跨站攻击。因为 CAS 要允许 App 跨域登录，必然要设置放行所有域名的 CORS 头，那么任何第三方网站就都可以发起对 CAS 的跨站攻击了。除非 CAS 预知所有 App 的域名，做 CORS 拦截，但这样就损失了业务扩展的便利性，新 App 必须提前向 CAS 注册。

#8 的描述是比较全面的，CAS 跳回 App 时带一个一次性的有时效的 Token ，App 后台向 CAS 查询这个 Token 的有效性并得到用户信息，此时 Token 失效。单个 App 存在漏洞也不会扩散影响到其他 App ，因为 Token 是一次性的，在有漏洞的 App 中用掉了就不能用在其他 App 中了。

前面两个方案的问题都是出在 CAS 返回的 Token 的有效次数上，在 Token 的有效期内可以任意次用于解锁任意服务，没有办法保证 Token 在使用后立即丢弃。第二个方案可以在加密／签名的信息中增加 App 名称做限制，但也存在伪造的可能性，因为 CAS 和 App 互相不知道提供的 App 名称的真实性，可能是由用户客户端的某个 XSS 脚本提供的。
而第三个方案则是补上了这些漏洞，由 CAS 和 App 互相在后台再做一次互认来实现。

@bigdoing 问题是，我看楼主说的是“构建代码瞬间”，而不是“保存代码的瞬间”，开始构建的时候应该不会去对源代码文件做写操作了吧，该保存的应该都已经保存完成了吧？
要清空重写的也是构建的中间文件或目标文件吧？但这些文件清空了也就清空了吧？

我猜测，应该是楼主使用了类似于支持 COW 的文件系统，文件写入是写到内存缓存，而不落盘，这时突然断电就会丢数据。
我 Linux 装的 btrfs 就是这个情况，如果突然断电，就可能会出现代码回退（代码变成修改前的样子）。如果在断电前不久操作过 git ，还会导致 git 仓库出错，表现为大部分 git 命令报错，删除 .git 之后重新 clone 然后把 .git 复制过来才行。