想到的最原始的方法就是先把坐标算出来存在数组里，然后取的时候每次从里面删一条，没啥算法可言了，相信应该有更好的方法勒~ https://reurl.cc/gQpdNX

@GoCoV2 看你 mock 数据的方式吧，如果通过前端直接拦截 XHR 或 fetch 异步请求这种方式，比如 Mockjs ，你一般会写 Mock.mock 来决定拦截哪些请求，不走 mock 的接口开发的时候注释掉就可以了；如果是 YAPI 之类的提供 mock 接口服务的形式，一般都会使用 DevServer 设置 proxy 代理转发来解决跨域的问题，proxy 里的 target 是可以设置不同 url 地址的，不同的接口不同的地址就可以了。不知道你的使用环境具体情况是怎样的了~

曾几何时，听到老家有老人过逝的时候还会怅然若失，再后来就变得麻木；终有一天自己的老父亲也走了，感叹生命无常也感叹自己的弱小；每天在大城市里上班、下班，如机器人般的生活让人好像一眼就能看到生命的尽头；曾经的我们对未来抱有无限期待，如小树般迎风生长，如今的我们漂泊在外，越来越像无根的树，没有了生气。或许，是我们自己变成了根，本就该生长在没有光的地方。

语言越底层越相当于直接与硬件打交道，逻辑处理就越复杂，人脑也就越难胜任这个工作，除了性能，效率、安全、测试、工程化等同样重要，而这些要求大多与直接操作内存的方式相悖，现代高级语言基本都朝这些方向发展。所以未必不让直接操作内存的语言就写不出高性能的软件，而可能是把内存操作的细节给封装起来了，现代编译器大多优化得足够好，编译出来的底层代码未必比普通人写的性能差。所以，能不能直接操作内存不是考核能否写出高性能软件的前提条件，不然现代语言就停留在汇编、C 就好了，而真正能不能用好语言、选择合适的语言干合适的事情才是最重要的，毕竟代码都是人来写的~

掌握左边的头发往右边搭看上去还很协调这门技术的时候~

@Kaier 牛批，形象~

@gzf6 我也没太明白你的问题的核心在哪，还是回归标题，Rust 跨平台是因为它可以将代码交叉编译成支持不同平台的代码，对应的就是 rustc 时的 target 参数，这里有 target 的列表和解释，https://doc.rust-lang.org/nightly/rustc/platform-support.html 看 target 的名称就可以知道，比如 Mac 上的 target 是 x86_64-apple-darwin，最重要的是两部分，首先是对应的是芯片 CPU 的架构（也就对应了二进制机器码指令集），这里是使用的 Intel 的 x86 架构，如果是 ARM 版本的 Mac，对应的 target 就是 aarch64-apple-darwin，使用 ARM64 位架构的指令集；另外就是操作系统名，这里是 darwin，对应也就是 macOs，有了这两部分，就能确定你的程序最终编译的二进制机器码该是怎样的。而 Wasm 跨平台是因为它提供了一套虚拟指令集，说是虚拟指令集是因为它并非像 Intel 的 x86 架构和 ARM 的 arm64 位架构那样，是提供用来制造真正的芯片的，Wasm 的真正执行还是通过对应的宿主环境实现的，然后比如在 mac 里最终的代码执行还是以 x86 或者 arm64 的机器指令来执行的。所以 Wasm 的跨平台是因为它处在比它的宿主环境浏览器或操作系统等更高的层面上，不管是什么平台架构，Wasm 代码都是用它自己的一套指令集编码出来的同一套代码，真正不同的是执行它的宿主环境能将 Wasm 的二进制机器码转译成对应平台架构里的真正机器码指令来执行，可以大致的理解为宿主环境运行了一个虚拟机，可以用来解释运行 wasm 代码，类比到 @hronro 说的那样，这个虚拟机就是 JVM，而 wasm 二进制代码就是 java 字节码~

先得区分下 Wasi 和 Wasm：Wasm 提供了一套栈式虚拟机的指令集，包括二进制(类似机器码)和文本两种表达(类似汇编)，因为 Wasm 指令集的定义并不与 WEB 挂钩，因此不止浏览器可以实现它，也可以是其它的运行时程序甚至可以是一个操作系统。我们可以把这些实现了 Wasm 的浏览器、运行时、操作系统等看作是实现 Wasm 的宿主环境，我们也可以通过 Wasm 指令集提供的能力与宿主环境进行交互，比如将浏览器的 console.log 方法导入给 Wasm 内调用(实际可能有点复杂，因为要涉及到数据内存结构的转换等)，总之，我们可以通过编写 C/C++/Rust 等语言的代码，借助一些实现了宿主环境代码到 Wasm 代码转换的库，比如针对浏览器环境里 C/C++有 emscripten，Rust 里有 wasm-bindgen，就能实现编译后的 Wasm 代码跑在 Wasm 虚拟机里但还能调用宿主环境提供的方法等能力。而 Wasi，相当于提供了一套标准接口，可以使得 Wasm 也能获得文件访问、网络、标准输入输出等与系统相关的能力，宿主环境如果想要提供这些能力供 Wasm 调用，就可以通过实现这套接口标准，提供给 Wasm 使用(可以大概理解为一套标准的方法集，与前面提到的 console.log 方法相似，由宿主环境实现，供 Wasm 使用，然后就可以将 C/C++/Rust 等代码中对前面提到的文件、网络等的操作转换为标准的 Wasm 代码)，当然这些标准代码能否正常执行则有赖于宿主环境是否实现了 Wasi 。我的大概理解是这样的，可能并不完全准确，可以参看[wasi 示例]( https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-tutorial.md#running-common-languages-with-wasi) 应该可以有个大概了解~

@ccsulzf0627 可以的，如果是固定的一些类型，可以定制下需要配置的表单，填字段名、字段项数、选择字段类型、配置类型支持的属性参数，大概这样的。最近也在考虑怎么能比较好的把这些类型的属性数据暴露出来，好方便用来提供给生成这种配置表单使用，这样就能动态的根据类型做出各种不同的配置而不用依赖于具体类型定制了。

如果是想判断正则表达式字面量是不是个合规的正则表达式，可以简单的验证一下：
```javascript
const isRegExp = (rule) => {
if(/^\/.+?\/[imdsguy]*$/.test(rule)){
try{
return new Function('', `var __rule__ = ${rule}; return __rule__ instanceof RegExp;`)();
}catch(_e){
return false;
}
}
return false;
};
console.log(isRegExp('/a/b')); // false
console.log(isRegExp('/a/i')); // true
console.log(isRegExp('/a/ii')); // false
console.log(isRegExp('/[a-z]/i')); // true
console.log(isRegExp('/[z-a]/i')); // false
```
正常的逻辑判断基本够用了，但上面的还是阻止不了一些特意规避的写法，比如像下面这样写：
```javascript
console.log(isRegExp('/a/;/b/')); // true, 考虑到斜杠 /在字符 sets([/])里是不需要转义的，所以也不能简单的判断 /是否前面有反斜杠\
```
要想完整的判断只能解析正则表达式的语法，但语法层面你还得考虑到浏览器对正则表达式的支持程度，比如是否要支持命名分组、\p unicode category 、负向前瞻等等，要做到完善还是需要考虑很多细节的。

如果不考虑哪种浏览器的话，Firefox 自带的截图功能应该是推出得最早、也最强大完善的~Chrome 插件的话用过 Fireshot，感觉还可以~

@wxsm 👍🏻 是个好办法啊，不过看了下 xpath 里 contains 方法和 jquery 里的:contains 选择器还是有些区别的，如上面所说，xpath 里匹配到的文本必须是在元素的文本子节点里连续存在的，相当于获取到元素后，再遍历元素的所有文本子节点看是否包含，比如『<div>ab<span>c</span></div>』，在 xpath 里是只能匹配到文本『 ab 』而不能匹配到『 abc 』的，所以看实际需求了，如果你的需求就是如 xpath 的处理方式一样，那原生的就能满足了，如果是如 jquery 的处理方式，那就不如直接引下库了~