YuJianrong

@FishBear 作为作者，我要说明一下 fast-array-diff 不是用在这个场景的。
fast-array-diff 是为了找出一个有序系列转换到另一个有序系列的步骤。
这个问题的场景是无序的。

GPT4:

对于 VSCode ，持“画蛇添足”的态度，不太提倡使用。它“鱼龙混杂”的扩展支持方式，想要完善地支持 Java ，实则“望梅止渴”。因为 Java 生态“博大精深”，其版本与工具“层出不穷”，所以需有“专心致志”的框架来整合。若非如此，开发者会“应接不暇”，难以“专心做事”。

稍微有点过了。

@justdoit123 这其实是历史问题。
当 Douglas Crockford 发明 JSON 的时候，其实只是为了 Javascript 方便用，就直接借用了 Javascript 定义 Object 的方式来制定 JSON 标准（所以 JSON 全称是 JavaScript Object Notation ）。但他懒到根本没有按 Javascript 的 number 来定义 JSON 的 number 类型，JSON 的 number 在标准上并没有任何限制。在你的场景下你觉得 int64 的 JSON 数字在 JS 读不出正确精度是 bug ，但同样别的 app 也可以写一个 BigDecimal 转出来超过 int64 的大数，你的 app 同样不能正确读出来，也是 bug 。

所以为了互操作性，不管在什么环境下 JSON 遇到数字的时候都应该当作 double 来处理，这样最不容易产生问题。

ref： https://en.wikipedia.org/wiki/JSON -> interoperability

大概率是诈骗电话。
国内谁闲得没事给你打跨国电话只为了宣传反诈……

估计再过一段时间会有宣传冒充反诈来诈骗的诈骗电话 🫠

@Mark24
赞成。不过有一点不同意，何止 type 不重要，type 不过是冰山一角。
计算机应该为人类服务，而不是人类为了计算机（和硬件细节）去定类型、算法、类等等一系列非人类的东西。
以后写程序就应该是对着计算机口述要求，计算机就自动 0 bug 运行起来。

这样可能会有 bug ？嘿，没 bug 本来就是应该打破的幻想。

我的建议是有条件直接上 Graphql 。
不要理睬那些 Resuful 原教旨主义者。

这是 Conditional Types( 就是这个：x extends TypeA ? A : B ）的特性。
做 Conditional Types 的时候，Typescript 编译器会把 union 分开一个个 map 去算，然后再合成一个 union 。所以

A<Type>
相当于
A<Type.Title | Type.Input>
相当于
(Type.Title extends Type ? _A<Type.Title> : never) | ( Type.Input extends Type ? _A<Type.Input> : never)

你直接 _A<Type> 当然就没有这个效果了。

文档： https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#distributive-conditional-types

看了一下 CDPR 的北美 office 在温哥华。那社招还是可能的，加拿大工作签证比美国好拿多了。
当然先过去留学容易点，要走社招路线的话，先找个外国游戏公司的中国部门（比如 ubi shanghai ），以后社招跳会比较容易点。不进游戏外企直接跳就太难了。

@JaaaaackZheng 当你在一个 Canvas 里用 DrawImage 绘制一非同源又没有 CORS 的图片的时候，这个 Canvas 会处于“被污染”（ tainted ）状态了。处于“被污染”状态的 Canvas 这些调用将会抛错：
* Context 上的 getImageData()
* Canvas 上的 toBlob(), toDataURL() 和 captureStream()
这样来防止比如 OP 这种想抓图片内容的做法。

详情： https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image#security_and_tainted_canvases