爬虫这种典型的重 io 任务当然应该开多 threading 或协程一起跑
你是这么爬的吗

vscode 关前端什么事....我写单片机嵌入式代码都用 vscode
甚至我写博客写小说都用它

「点击这个应用程序 M,实现在线编辑文档。」

「因文档较大，不考虑使用在线的例如 OnlyOffice 的编辑 。」

你到底要在线还是不要在线
后者的话绑个 scheme 协议点击打开 word 完事

zen browser
compact mode

scp remote1:/path/to/source remote2:/path/to/destination

只要别是亮色主题就行，都差不太多

@assiadamo
我精简了一下你的代码，你看看哪里不符合你的需求? 我就直接用了你的业务逻辑
https://go.dev/play/p/zCDaPEkuPL3

@assiadamo 你要不写段完整点的代码，发 playground 或 gist 都行，我看看你到底要做成啥样
至少从你的文字里我还是没法理解你在框架外面写的逻辑为啥还要传回给框架

@assiadamo 所以你还是在外面写逻辑不是在框架里写，那你在外面写了外面调就是了为啥一定要传回去?

这个特性就是原本手搓的
const [isLoading, setIsLoading] = useState(false);

const onClick = async (e) => {
setIsLoading(true);
await some_action();
setIsLoading(false);
}

给你个 hook 省得写起来啰嗦
实用性还是有的
但要说多大革新那就想多了
原本就能轻松实现的功能

@assiadamo 业务逻辑总是要写在一个地方的，不是写包里就是写外边，你不就是要让业务那边不管框架怎么处理只专注业务本身并且不需要重复写函数定义吗。
如果这样还不行那恕我实在没法理解你的业务逻辑到底想写在哪。

@assiadamo
譬如我现在定义两个 struct, 或者按你的说法是协议
type EncStr struct {
Raw string
Encoded string
}

type DecStr struct {
Encrypted string
Decoded string
}

我要在业务里 Process 他俩，譬如打印出人能看到的信息，也就是在 EncStr 里的 Raw 或 DecStr 里的 Decoded
那我在业务里先定义一个 interface
type Protocol interface {
Print()
}
再定义一个
func Process(p Protocol) {
p.Print()
}
这时候业务里只有他俩就够了

回到前面定义协议的地方，加上下面的内容
func (e *EncStr)Print() {
fmt.Println(e.Raw)
}

func (d *DecStr) Print() {
fmt.Println(d.Decoded)
}

然后你在业务里调用 Process 函数就行了
https://go.dev/play/p/IaPb1GktEsS

@assiadamo
那我基本确定了，你可能没太理解 interface 的本质
Go 里的 interface 就是为你说的这种应用场景准备的
你不需要给每个协议都生成一个 Process ，
只需要定义个 interface ，再定义单独一个 Process ，用这个 interface 当参数类型
然后在框架里给每个协议定义好 interface 需要用到的方法就行

这样就是业务完全不需要管框架里怎么实现 Process ， 直接定义一个协议结构体变量，然后 Process 它即可

@assiadamo 我试着理解你的意图：你是不是想定义一个 func Process() , 这个 Process 的参数可以是 Echo 类型的量，也是跟 Echo 类似的还有几百上千个的其他结构体的变量，你不想为这些结构体里一个一个定义 Process 函数？

@assiadamo 所以你的意思让框架猜你的业务逻辑？

@assiadamo 你一边说不想在框架里写业务，一边又说直接调用框架里的方法执行业务逻辑，你到底想说啥?

@assiadamo 那就直接在 logic 里定义 Process 啊，proto 那里那个不用了呗

在我看来只需要定义
func Process(msg *Echo)就够了，再来个 ProcessEcho 意义何在

好奇心旺盛怎么会是 debuff
好奇心不匹配学习能力才是
试想一下如果你每次冒出 why 以后最多只需要用 10 分钟就能找到原因解决问题并吸取教训成为经验，好奇心还会是 debuff 吗?