@misdake 看错问题了，刚才以为是求最高位在第几位。
求位数的话，我想就不断乘以 10 判断还有没有小数。

对于正数，取以 10 为底的对数，比如 log10(0.05)=-1.30103，需要+2 才能大于 0，所以是小数点后第二位
用这种数学方法的话，不同的计算方式可能有误差，需要注意，0.3-0.2=0.09999999999999998

lz 的意思我觉得是先抛一个硬币决定乘和除，然后随机一个 1~2 之间的数字，用当前值乘或除(根据硬币)这个数。

1.
你看你的代码，你得到的结果似乎是“假设手上有一些重量不等的砝码，使用 2 个砝码来称重(不多不少，必须是 2 个)，可以称哪些重量”
而不是“假设手上有 N 个重量不等的砝码，可以称哪些重量”

2.
你碰到的重复计算的来源是：每一次想要扔掉一个元素的时候，都遍历整个集合
会出现“先扔掉 1 再扔掉 2”和“先扔掉 2 再扔掉 1”的两种调用，但谁先谁后在这道题中无所谓，重复计算了。
为了避免重复计算，应当舍弃掉这两种情况中的 1 种，如总是要求“扔掉的数字必须必上一次扔掉的数字更大”

我觉得可能的一种 145623 的运行顺序：(不保证正确)
第一个 console.log(1)的时候，发起了刷 buffer 的请求，输出 1 。接下来的 bcde 因为没赶上这次的输出，被压进了主线程的 buffer，等待下一次刷新。
worker 线程在跑的时候，1“正在”输出，刷新时 worker 线程的 buffer 里已经有 456 了，输出 456 。(猜测不同线程的刷新是轮询的，而不是优先盯着一个)
下次刷主线程 buffer 的时候，buffer 里有 23，输出 23 。


如果在 isMainThread 判断之前加上一句 console.log ，提前刷一下 console.log 的 buffer，输出的顺序应该就和你想象的一样了。感觉就是 buffer 相关的原因。

"（开发软件时）前 90%的代码要花费 90%的开发时间，剩余的 10%的代码要再花费 90%的开发时间。"

图片生成就和上传时候提示你选择封面那个图一样，在上传之后就会截取一些关键帧，拼成这么一张图保存起来。

某一个视频的图片： https://i0.hdslb.com/bfs/videoshot/[email protected]
图片里有很多子图片
把这个图片作为鼠标进入时，上面一个层的 background 。上面这个层上放一个 mousemove 事件，根据鼠标位置，修改 background-position，设置显示哪一张子图片。

可以尝试一下导入到官方 editor 里看看效果： https://threejs.org/editor/
如果能看到，说明 threejs 本身应该是支持的，但是可能是你的项目中的物体位置(比如三角形不在视野内)、相机(比如 clearcolor 黑色，物体也是黑色导致看不出来)或者灯光(比如物体本应不黑但是没有光照导致是黑的)有什么问题。
如果看不到，说明导出的 obj 或 mtl 格式可能有某种不兼容(但不报错)的情况(比如材质透明了或者没设置上)。

严格来说 “32 位的系统能表达的内存位置只有 2 的 32 次方个，也就是 4G” 其实应该是 “同一时刻，单个进程能寻址的内存位置有 4G”
多个进程(使用不同的页表)、或者不同时刻(修改页表前后)，都可以某种程度上突破这个限制。

在最理想的情况下，在创建所有可能性之后，想要剔除掉不正确的答案也要 O(n)次检查吧

先用下载工具下下来，再用 ffmpeg 分离

我猜类似炉石分享套牌的方法可能比较合适，可以搜一下。

如果需要在浏览器里解压，那么解压算法就必须知道这几个词。需要下载的应该一个定制的压缩算法和一个预定义字典。
我觉得和正常的压缩算法相比，压缩比提高不了多少，不可能抵消掉压缩算法+预定义字典的下载体积和时间。

另外根据你提供的例子，可能可以用二进制内容直接做。

@PepperEgg https://www.bilibili.com/video/BV1bs411t7Y9?p=4&t=1670
"Is there some best practice about using 'const' anywhere possible?"
"If you do not currently use 'const' anywhere you can, I bet you will after this talk."

let max = Math.max(...Object.values(params));
Object.keys(params).filter(key => params[key] === max) // ["i", "c"]

实在不行没招了的话，可以搞个 android 机，写个程序读通知和短信然后把内容发过来

如果对安全性毫无要求，甚至可以直接随机一个密钥，用某种对称加密算法来加密。分享的时候同时提供密文和密钥。

要用某种可反向操作的规律向输入数据中加一些冗余且相对随机的数据，用某种一一对应地编码跑一遍生成“密文”，解密的时候把冗余数据剔除，重组成原文。
用你上面 base64 的例子的话，如果安全要求不高，可以在输入的每个 bit 之间都插入一个随机的 0 或 1，然后 base64 。解密的时候把中间的 bit 都去掉重组。