@coolpace #48 试了一下，效果非常不错👍

请你喝杯奶茶~

很好用，用了很久了。

顺带问一下，作者考虑添加个 option 在 Windows 上适配 Noto Sans 么？目前 Chrome 系应该是遵从微软建议，默认采用 Noto Sans 作为默认字体了，在 2160P 200% 缩放下，显示效果要好很多。

Windows Terminal 支持 SSH panel 了，会折腾 `~/.ssh/config` 的话，直接 Windows Terminal 使用就好了
* SSH panel 行为和 vscode 一样，会列出所有配置了的 ssh 服务器

指令遵从性比 opus 4.5 差很多。
经常定义了多个 Phrase ，比如说 Phrase 2 调用 Codex ，Gemini 进行多模型分析需求，会被主动跳过。
再比如生成代码原型，后端使用 codex 生成指令会高很多，opus 4.6 往往选择这时候跳过。
最重要的是实施完成后，需要进行代码指令控制，使用多模型审核，以及单元测试，一不注意 opus 4.6 就跳过了。
Opus 4.5 在使用相同的 skills 和 prompt 都没有这样的问题。

以及在调试错误，opus 4.6 会陷入死循环。比如说测试失败，需要更新一下 snapshot ，尝试方案 A->B->C->A 会循环重试。
* 而 Codex 5.3 在尝试 2-3 cycle 后就解决了
* Opus 4.5 虽然不能解决，但是也能告知可能路径，不会循环重试

跟一个

那个 React Compiler 是一个 babel 插件（至少目前是），而且还没有 stable ，不是 React 19 内嵌的东西。opt-in 使用的。

拿一下 dump 文件，用 windbg 看一下。有可能是驱动问题

@Pylogmon 缺少优越感 🐶

这价格同出

造，没看 PS ，上条无视

GitKraken

ZFS 的好处是安全性啊……我之前缓存盘用的 BTRFS ，然后就没了。损失了四五百 GiB 的数据（还包括了局域网的 Gitea 数据容器）😭

@chill777 #24
1. 我要表达的意思是，这个和你用 ESM ，CJS 无关。他这种用法就相当于声明了个 JS 对象，然后 export 出去，这是很明显的单例用途把。只不过放在了模块上了。
2. 争论点，或者说差异就在是否有必要使用生命周期上。如果单例够用的话，2 能用。如果单例会污染数据的话，那肯定是抽象 hooks ，或者说组合式 API 更合理。这点我的看法是和 #2 一样的。
3. 抽象（解耦）不就是和耦合对立的？一块通用逻辑提取出来，不叫抽象一个组件，一个模块出来吗？

👍👍👍👍👍路上看到了，直接开润

@chill777 #21 1. 我可以 export {} 也可以 module.export = {}。暴露一个 JS 对象出来而已，我觉得直接称呼 ESM 不妥当。
2. 全局状态管理里面没有 dispatch 的概念吗？这是不是一种逻辑复用呢？

3. 是你问的：“所以这种做法是可以的吗？”。我就这句做回答：“是可以的”。所以有什么问题呢？

如果你问是否是合理的话：此模块涉及生命周期的话，抽象成组合式 API 当然是更合适的。其他情况的话，结论就是都可以。看你们团队的喜好。

1. 这和 esm 没关系。
2. Vue 里面的响应式包 `@vue/reactivity`，比如 reactive 啥的都可以脱离 setup 使用。所以他第二种做法是可以的。

P.S pinia 里面的 introduce 里面就有提到，为啥要用它，不用第二种（直接使用 reactive 做状态管理）。其中最大的优势就是 SSR 友好。https://pinia.vuejs.org/introduction.html#Why-should-I-use-Pinia-

似乎可以试试 sonic ？不需要你手动做缓存啥的方案了。
https://github.com/bytedance/sonic/blob/main/docs/INTRODUCTION_ZH_CN.md

@Forviler #33 😀好