@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) # 参数不能自动推导，要写。返回值能自动推导，不写。

@Chad0000 #159 #160
国外市场化了吧，但也没见大规模搞这种东西，说明这是违反市场规律（甚至物理定律）的做法。

既然脑洞都到这个地步了，还不如更进一步，去脑洞汽车自动驾驶，灵活性吊打任何轨道交通。想去哪就去哪，没有铁轨的束缚，出门直奔目的地，而是傻傻地往火车站挤。

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

高速动车组采用的是密接式车钩，出厂之后一般是不能解编的，不像老式普速车辆那样随便拆分组合。

就算不考虑车钩问题，你也要想想，在火车站加挂、解挂，也是非常耗时的工作。意味着站台、线路都要被长时间占用，影响车站接发车效率。然后就是车辆停车时间加长了，也影响车底周转时间，以前能跑 3 趟的，因为频繁加挂解挂耽误时间，只能跑 1 趟了。

写 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 前端这种缩进地狱多发区，按道理应该喜欢这个功能的呀？🐶