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

系统设置里搜 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 年了，主流浏览器是肯定都支持的。