首先你肯定得重构代码，我这里提供一个较为简单的方案
开一个池子
class MyPromisePool {
#data: Promise<void>[] = [];
add(promise: Promise<void>) { this.#data.push(promise); }
async [Symbol.asyncDispose]() {
await Promise.all(this.#data);
}
}
在顶层函数使用，例如
async function entry() {
await using pool = new MyPromisePool();
//需要的时候就往 pool 里塞 promise
pool.add(asyncfn());
//尾部不用手动写其他代码，ts 会帮你生成合适的代码
//会自动调用 Promise.all 去等待结束
//侵入性更小* （意味着不需要去跟踪函数是怎么结束的，你直接写 return 就好
}

大概率就是用 chrome 原生的 view-transition api 做的过渡呗。。。
那玩意吧单独用其实挺难做对的，但是效果确实炫酷，还不需要写太多 js

不过我觉得运行时检查类型，可能对一些复杂的类型处理不好，比如 ts 那边经常用的一些伪名义类型技巧引入的虚拟元素（实际对象中不存在，仅为了触发 ts 的名义类型模式）

@CHTuring 看介绍实际上是支持 ts 的
运行时检查还是不太一样的吧，不过说到底也只是给开发阶段用的，ts 好好写能避免第一方的类型问题，但项目不可避免的会引入第三方代码或一些难以在 ts 框架下描述的类型，用了 any 一类的逃生仓，就有可能出现运行时类型不符合预期的情况

https://github.com/xpodev/extype
也不是完全不行，用原生扩展包里改

@famanoder svg 转字体本身就比较灵车，彩色的更灵车了（）
一般主要是用在 ligature 方面上的（也就是说在图标没加载出的时候显示文字，字体加载好了文字变成图标）在一些可访问性方面会好（屏幕阅读器用户）

字体图标是可以多颜色的，不然你以为彩色 emoji 是怎么实现的
就是 COLR 表去标记颜色就可以了

根据 json 的定义，就是只支持 utf-8 的，你 unicode 通过\u 转义没有改变它表达的还是 utf-8 文本的核心（也就是说不能用来传递非法 utf-8 的字符串），我能想象到的场景是某些信道不支持 utf-8 文本，这种情况下不如在输出 json 文本后进行一个后处理

https://json.nlohmann.me/home/faq/#wide-string-handling
手动转换成 utf8 就好了

理论上这个库应该能处理 unicode 的呀

因为 c++有引用的概念，所以可以用引用来表达返回左值的类型，而*p 作为表达式是左值表达式，decltype 对左值表达式使用时，返回引用用来区分其他值类别

这种东西古代还可以搞搞，因为当时的网页都不怎么复杂，基本上还都可以做可视化（比如你现在在地址栏输入 javascript:document.body.contentEditable = 'true'就可以一键启用浏览器内置的编辑模式）
但很显然稍微复杂一些的页面就不太行了，很多布局不是能随便拖动的）
不过现在是 2024 年，理论上可以上 ai ，现在也有不少根据草图生成网页的模型

rdp 的时候是纯 cpu 渲染（包括集成显卡也不会被使用）

@est 然后发现不同平台有不同的本地库依赖：比如常见的那些机器学习项目，直接复制的话几乎肯定会炸（ win->linux)

你这文字弄起来也太难阅读了吧。。。
中文窄，英文宽，这能读？？

虽然我觉得大概率是写错了（）

说白了就是早起项目设计的问题，一开始没做好依赖隔离的机制（全局安装包），只能后期不断打补丁解决。。。

可以用 experimental 里的 unstable_Activity

我建议要发异步请求什么的，用 swr 这类库去处理吧，之后 ssr 和服务端组件都可以用上