@Ghrhrrv146
其实就是 try finally 的语法糖。
不过我感觉这种写法相比 try finally ，除了不用套一层作用域外，还有一些好处。
比如资源的申请和释放可以挨着写在一起，不容易遗忘；
还有就是如果有多条 defer 回调，这些回调的实际执行顺序跟书写顺序是相反的，类似后进先出的栈模型，也符合多数情况下的资源释放的逻辑。

JS 的 Explicit Resource Management 有类似的实现，应该就是学 C# 来的，已经进入 Stage 3 了。

{
using stack = new DisposableStack();
console.log('start');
stack.defer(() => console.log('defer'));
console.log('end');
}

以上运行结果 start 、end 、defer 。

如果发生异常，defer 也会执行
{
using stack = new DisposableStack();
console.log('start');
stack.defer(() => console.log('defer'));
console.log('next');
throw new Error('error'); // 异常
console.log('end');
}
以上运行结果 start 、next 、defer 。

建议把 data 和 visibleData 都改成浅响应（ shallowRef ）。
我推测 orderBy 在处理 list 的时候，因为 vue 的响应式处理造成了过重的负担。

我觉得只有经历过 callback hell 时代，才能理解为什么会有 promise ，为什么会有 async/await 。
所以建议楼主先写一段时间 callback ，自然会慢慢理解了。

跟 TS 、JSDOC 一样，编辑器能自动推导的类型不写，只写不能自动推导的类型。
因为编辑器提供智能提示，非常爽。🐶

v1 = 'string' # 这里不写
v2 = 1 # 这里也不用写

def func(arg: SomeType) # 参数不能自动推导，要写。返回值能自动推导，不写。

要不去学 java spring 看看，说不定只是不适合做前端。

写 TS 就是为了智能提示。
21 世纪了，还提供不了智能提示的编程语言，像个瘸腿的残疾，只能算能用，但用得痛苦。

目测是一个 X-Y 问题，建议把你的根本需求说出来，而不是问一个自以为的解决方案。

内存不足是由“已提交”（任务管理器也有显示）决定的。
即使你的内存看似还有很多空间，但要是“已提交”满了，也会报内存不足。

@mandex
不如这个🐶
https://imgur.com/iqs5qUu
https://i.imgur.com/iqs5qUu.jpeg

@shuimugan
Angular1：果然人都是健忘的

文件管理器卡。
最小化的文件管理器，有时莫名其妙地跳到前台。
任务管理器卡。
开机后，首次打开音量调节面板，初始化极慢。

那个年代分 4 个区，其实是因为盗版系统的一键 ghost 默认就是这么做的，多数用户并不在乎怎么分区。

我不明白呀，按道理 PCDN 应该吃流量，而不是吃 CPU 算力的，不应该造成 CPU 跑满风扇狂转的。
这种现象更像是挖矿。

@jqtmviyu
主要是像 UI 组件的嵌套，不好拆。
然后是 object 字段、方法，callback ，再加上几个 if forEach map ，很容易出现深层嵌套。
这也是 JS 、HTML 开发习惯用两格缩进的原因。

奇怪了，web 前端这种缩进地狱多发区，按道理应该喜欢这个功能的呀？🐶