@waiaan 因为 with 最内侧的优先级最高，先找到的就调用了，全局函数是最外面的

@3dwelcome 说错了，submit 方法的默认行为是触发 submit 事件，然后根据是否 preventDefault 来决定是否执行提交行为，而 onXXX 事件绑定机制是当返回 falsy 值时 preventDefault ，因此当你同时定义 onsubmit 和 submit 方法时，两者将独立工作互不影响（（通过 type=submit 按钮触发的会发送 submit 事件，然后如果没被 preventDefault 就执行原生提交程序（与 submit 函数无关）；而通过 submit 方法手动调用的就会进入你自定义的函数上，也不会触发事件（除非你手动 dispatchEvent ）

@waiaan 并不是，对于任意通过 onXXX 绑定的事件处理函数都有类似 with 的处理逻辑（不在 form 章节里，但是 html spec 太长了，不是很想找。。。），显然你这里用的是 oninput

@3dwelcome 问题在于，你 onsubmit 如果改成一个返回 truthy 指（也就是可以转换成 true 的表达式），原本的 submit 依旧会被执行（ console.log 刚好返回 undefined ，所以会自动阻止原本 submit 方法的执行（

关于楼主的这个问题，你可以把 onclick 改成 debugger ，然后开 F12 看一下，它实际上有多个 with 上下文
相当于所有在 onXXX 属性里执行的代码都会变成
with(document) {
with(form) {
with(input) { //以此类推，就是每个上级元素
xxx
}
}
}
的形式，我记得之前在 html spec 里看过，不知道哪位老哥可以给出引用

@3dwelcome onsubmit 是事件绑定（和 submit 方法没有直接联系

设置界面建议加点 padding ，这啥都顶格+双层边框实在不是好设计（

用 extglob 还是太扭曲了(需要开扩展，而且 zsh/bash 都不一样)。。。
给个稍微长一点，但是不用这么扭曲的方法吧
LIST=(*)
mkdir newDir
mv ${LIST[*]} newDir

@tabris17 生物识别无法辨识是否是用户主动操作，其次现有手机识别机制以速度和可用性为目标，准确性不是（你看人脸识别各种口罩遮盖都可以，指纹用湿手也有概率可以通过）更不要说指纹本身还可以被轻易复制，且被复制后就无法修改。
别看密码或者图形验证很短，在一定安全机制——限制尝试频率——之后，破解还是有一定难度的（非要说 bypass 安全机制的话，那啥手段都一样）

(你这 translateX 单位都不写

我可以永远不看（并且多数情况是这样），但是你不能一点不给我看历史记录的机会

为了安全性的话，可以考虑用 firecracker ，通过轻量级虚拟机运行订制内核(
不过 rootfs 还是得靠自己提供

Chrome 倒是可以在 flags 里改
chrome://flags/#unsafely-treat-insecure-origin-as-secure

@ysc3839 可以防读取，但是要捐赠

有没有一种可能，keto 在线下和线上同时打广告

说起 emoji ，目前 github 用 emoji 做分支名还会触发各种 500 错误

@2i2Re2PLMaDnghL 视为单个空格和处理内容为单个空格不是一个概念，两种处理方法都是合理的，本质上是这个问题没有良好的定义

十年前走进商店买数据线：Micro-USB ，Mini-USB ，USB-A ，USB-C......这都什么玩意

USB-IF：我们要整一个统一的接口，以后很多设备都是这个口

我：好耶

手机厂商：hAo yE ！

买数据线的我：
USB-C （ USB2.0 ），USB-C （ USB3.0 ），USB-C （ USB3.0 E-Marker ），USB-C （ USB3.1 Gen1 E-Marker ），USB-C （ USB3.1 Gen2 E-Marker ），USB-C （ USB3.2 Gen1 E-Marker ），USB-C （ USB3.2 Gen2 E-Marker ），USB-C （ USB3.2 Gen2×2 E-Marker ），USB-C （雷电 3 E-Marker ）

USB-C （ USB2.0 PD2.0 ），USB-C （ USB3.0 PD2.0 ），USB-C （ USB3.0 E-Marker PD2.0 ），USB-C （ USB3.1 Gen1 E-Marker PD2.0 ），USB-C （ USB3.1 Gen2 E-Marker P2.0 ），USB-C （ USB3.2 Gen1 E-Marker PD2.0 ），USB-C （ USB3.2 Gen2 E-Marker PD2.0 ），USB-C （ USB3.2 Gen2×2 E-Marker PD2.0 ），USB-C （雷电 3 E-Marker PD2.0 ）

USB-C （ USB3.0 E-Marker PD3.0 3A ），USB-C （ USB3.1 Gen1 E-Marker PD3.0 3A ），USB-C （ USB3.1 Gen2 E-Marker P3.0 3A ），USB-C （ USB3.2 Gen1 E-Marker PD3.0 3A ），USB-C （ USB3.2 Gen2 E-Marker PD3.0 3A ），USB-C （ USB3.2 Gen2×2 E-Marker PD3.0 3A ），USB-C （雷电 3 E-Marker PD3.0 3A ）

USB-C （ USB3.0 E-Marker PD3.0 PPS 3A ），USB-C （ USB3.1 Gen1 E-Marker PD3.0 PPS 3A ），USB-C （ USB3.1 Gen2 E-Marker P3.0 PPS 3A ），USB-C （ USB3.2 Gen1 E-Marker PD3.0 PPS 3A ），USB-C （ USB3.2 Gen2 E-Marker PD3.0 PPS 3A ），USB-C （ USB3.2 Gen2×2 E-Marker PD3.0 PPS 3A ），USB-C （雷电 3 E-Marker PD3.0 PPS 3A ）

USB-C （ USB3.0 E-Marker PD3.0 5A ），USB-C （ USB3.1 Gen1 E-Marker PD3.0 5A ），USB-C （ USB3.1 Gen2 E-Marker P3.0 5A ），USB-C （ USB3.2 Gen1 E-Marker PD3.0 5A ），USB-C （ USB3.2 Gen2 E-Marker PD3.0 5A ），USB-C （ USB3.2 Gen2×2 E-Marker PD3.0 5A ），USB-C （雷电 3 E-Marker PD3.0 5A ）

USB-C （ USB3.0 E-Marker PD3.0 PPS 5A ），USB-C （ USB3.1 Gen1 E-Marker PD3.0 PPS 5A ），USB-C （ USB3.1 Gen2 E-Marker P3.0 PPS 5A ），USB-C （ USB3.2 Gen1 E-Marker PD3.0 PPS 5A ），USB-C （ USB3.2 Gen2 E-Marker PD3.0 PPS 5A ），USB-C （ USB3.2 Gen2×2 E-Marker PD3.0 PPS 5A ），USB-C （雷电 3 E-Marker PD3.0 PPS 5A ）

USB-C （ USB2.0 SuperVOOC ），USB-C （ USB3.0 SuperVOOC ），USB-C （ USB3.1 Gen1 SuperVOOC ），USB-C （ USB3.1 Gen2 SuperVOOC ），USB-C （ USB3.2 Gen1 SuperVOOC ），USB-C （ USB3.2 Gen2 SuperVOOC ）

USB-C （ USB2.0 小米快充）

USB-C （ USB2.0 vivo22.5W 快充），USB-C （ USB2.0 vivo44W 快充），USB-C （ USB2.0 vivo120W 快充）

USB-C （ USB2.0 SCP ），USB-C （ USB3.0 SCP ），USB-C （ USB3.1 SCP ），USB-C （ USB3.2 Gen1 SCP ），USB-C （ USB3.2 Gen2 SCP ）

@amiwrong123 注意括号 然后假设每次都一致，这是前提条件。。。
来看标准吧，c++20 标准 6.3 节 13 小节
There can be more than one definition of a
... -inline function or variable ([dcl.inline]), ...
这是允许 inline 函数或变量有多个定义（即使同一个 TU ）再看需要满足的要求
(13.8)
Each such definition shall consist of the same sequence of tokens, where the definition of a closure type is considered to consist of the sequence of tokens of the corresponding lambda-expression.
每个定义都需要有相同的 token 序列
(13.9)
In each such definition, corresponding names, looked up according to [basic.lookup], shall refer to the same entity, after overload resolution ([over.match]) and after matching of partial template specialization ([temp.over]), except that a name can refer to ...... same entity in all definitions of D.
每个定义所引用的符号在重载解析，模板偏特化之后除了某些特殊情况外都必须解析到相同的实体上
最后
If these definitions do not satisfy these requirements, then the program is ill-formed; a diagnostic is required only if the entity is attached to a named module and a prior definition is reachable at the point where a later definition occurs
如果这些条件没有满足要求，那么程序是不合法的，而也只有特殊情况（同一个模块且在不一致定义要在同一个单元）才要求编译器给出诊断（报告错误）
所以一个不要求诊断的错误的代码（甚至不属于 UB ）给出任何行为都是符合预期的（链接期随意选择是结果的一部分而不是原因，写程序不是自然科学，不要用实验来推测原因）