@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 复制过来才行。

系统设置里搜 autoplay 或者自动播放，把开关关掉试试？

API 不兼容的升级，那么为了平滑过渡，新 API 和旧 API 要同时存在一段时间，然后通知迁移，给个 deadline 。deadline 前几天检查旧 API 的流量，如果还有人在用，就给对应业务方发最后通知，过 deadline 下线旧 API 。
应用调 API 需要强制标记业务方，这个对管理有益，业务方请求肯定是有封装的，统一加个参数也不麻烦（要是请求没有封装，散落在各个地方，这不重构留着过年？）

现在业务方没传业务标记的话，不妨统一升级一套 API ，强制传业务标记。这样出问题也可以很容易定位到具体是哪个业务出的问题。

round 、floor 、ceil 的使用场景：
首先，你期望得到一个整数（比如在针对物理像素点做优化计算的时候，必须使用整数）才会要使用这些舍入方法。
round 就是四舍五入，结果可能比原值大，也可能比原值小，但一定是最接近原值的。通常变化的值就用这个来舍入。
而 ceil 和 floor ，一个是向上取整，一个是向下取整。通常用于边界条件的时候。比如容器大小固定，那么内容就得用 floor 来向下取整，不然就可能会把容器撑开或者折断截断导致布局出错。类似的，如果容器大小不固定，那就要考虑使用 ceil 来进行向上取整，原因和用 floor 是是一样的。

如果你不是要手动根据密度之类的东西去针对物理像素优化的话，那完全没必要舍入，直接用小数，由浏览器渲染引擎来决定与物理像素的映射。

另外，滚动的边界条件浏览器应该是有处理的，滚动到头得到的事件参数值和取到的目标滚动参数应该是一样的。

@dzdh emmmm ，不知道我理解的对不对：
data:;base64,U0VMRUNUIENPQUxFU0NFKAogIChTRUxFQ1QgKiBGUk9NIGRvbWFpbnMgV0hFUkUgZG9tYWluID0gJ2FhLmJhaWR1LmNvbScpLAogIChTRUxFQ1QgKiBGUk9NIGRvbWFpbnMgV0hFUkUgZG9tYWluID0gUkVHRVhQX1JFUExBQ0UoJ2FhLmJhaWR1LmNvbScsICdeW14uXSsnLCAnKicpKQopOw==
用 COALESCE 分成两次查询，第一次绝对匹配，能匹配到直接返回，匹配不到的话，再进行第二次匹配。第二次先用正则把域名开头的子域名替换为 * 再进行绝对匹配。因为通配符证书只能匹配一级子域名，所以只需要 replace 一级。

P.S.: 额，直接发 SQL 被 CloudFlare 拦截了……

@leavic succeed：verb 动词，1. achieve the desired aim or result 达成预期的目的或结果，2. take over a throne, inheritance, office, or other position from 继承王位、职位等.
建议你多读一些英文文档，里用 succeeded 作为成功的场景挺多的。

男，没毛病
Massachusetts Institute of Technology ，没去过
棒球，没打过
名人与娱乐新闻，从不关注
烹饪和食谱，没兴趣

我们 Google 真的是太了解我啦！

@jinliming2 啊，不对，补充一下，1999 年 6 月 标准化的 HTTP/1.1 （ RFC 2616 ）只包含 307 状态码，用于标准化 302 的行为，但是没有给出 308 。
308 是 2014 年 6 月在 RFC7238 补充给 HTTP/1.1 的。
所以，308 的兼容性需要考虑一下。不过现在 2022 年了，主流浏览器是肯定都支持的。

@learningman 301 和 302 由 HTTP/1.0 引入，但部分浏览器对重定向后的请求方法实现不一致（ GET 请求跳转后还是 GET ，但其他请求跳转之后有可能会变成 GET ，也有可能不变，取决于浏览器实现）
308 和 307 由 HTTP/1.1 引入，分别对应 301 和 302 ，但是标准化规定了重定向后的请求方法与原始方法一致，保持不变。
303 现在用的很少了，表示重定向后请求方法变为 GET 。通常是用在表单 POST 提交后重定向刷新页面的（以前用原始 form 表单直接 submit ，POST 提交到当前 url ，然后再重定向回当前 url ，服务端 url 一样，根据 method 来判断执行的操作，使用 303 重定向后方法会变回 GET ）。不过现在基本上很少用 form 直接提交了，所以 303 用的就少了。

总的来说，就是部分浏览器把 301 、302 按照 303 来实现了，308 和 307 是用来纠正这个错误的。所以在 HTTP/1.1 之后是推荐使用更明确的 308 、307 了。HTTP/1.1 是 1999 年标准化的，所以可以理解是现在的客户端全部都支持的。

301 、308 表示永久重定向，所以浏览器会缓存目标地址响应，以后请求原地址在缓存有效的情况下都会直接自动转到新地址。
302 、307 表示临时重定向，所以浏览器不会缓存，以后访问原地址的时候还是会重新请求一下，看一下是否还需要跳转。

@xy2401 在英文 Google 上搜，出来的结果大部分是 What is SELinux 介绍 selinux 的，扫了一眼，看到几条不太一样的：
What is SELinux and Why You Might Want It
Why SELinux is more work, but well worth the trouble
Does SELinux make Redhat more secure?
Don’t Disable SELinux
Here’s why you should be wary of installing anything that sets SELinux to permissive

@dzdh 没看懂，什么叫“根据什么把传过来的参数给去掉呢”
SELECT * FROM domains WHERE domain ~* '^[^\.]+\.baidu\.com$'; -- 这个可以只匹配二级域名，而不匹配三级、四级等
如果你是想指定匹配一级域名的话，那比较困难，因为一级域名的后缀是一个很长的列表，比如 .com 、.cn 这类只有一个尾缀的，还有 .com.cn 这类有两个尾缀的，还有 google 这样的公司名域名（ https://domains.google ），还有 .中国 .中國 .香港 .個人.香港 这类一个尾缀或两个尾缀的中文域名……
列表应该是 https://raw.githubusercontent.com/publicsuffix/list/master/public_suffix_list.dat 的 ===BEGIN ICANN DOMAINS=== 到 ===END ICANN DOMAINS=== 中间的部分

docker 里装上 Chromium （或者把 puppeteer 下载路径持久化一下）