分享一下我的看法，我理解这些概念不太喜欢先深入细节，有全局视角再看细节

无栈协程的核心就是 把顺序代码变成一种状态机，不同语言的实现差异很大，但逻辑差不多

(其实我们如果不用 coroutine, 写事件驱动应用 就是手写这个状态机）

await 就是状态转移点，从一个 await 完成 到下一个代码路径上的 await 就是一次状态转移

将这一小段代码封装起来 就叫 task, 这就是 事件循环执行的基本单元（不同语言实现也不一样，python 应该是依靠 生成器状态机来实现，rust ，c++ 则靠编译器）

future/awaitable 作用是管理 task 之间的依赖关系，在某个 task 的 future done 的时候，将依赖它的 task 放进就绪队列等待执行（不同实现也不一样，比如 直接通过 callback ）

所以:


- 啥时候让出权限: 一个 task 完成的时候
- 啥时候任务加进事件循环： 这个任务的依赖 future done 的时候 （实现可以都不一样，单实践效果一定是这样的）
- 啥时候恢复执行: 进如 ready 队列了，就等待执行了，自于啥时候执行，就是 队列和 调度器的实现了，也都不一样

----


正好前段时间看了 foundationdb ，他们自己实现了一个 叫 flow 的语言，在 < c++20 上实现了无栈协程，它的编译器会把 flow 的代码编译成 C++ 的状态机，可以清晰的看到怎么把代码转成状态机

touch bar 对我很鸡肋，我无法适应需要我需要目光下移去看一个和屏幕不在一个平面上的东西，即便只要瞟一眼，割裂感也很严重

其实 更大可能是 reuse 了

“复杂性” 从来不来自技术本身，而是来自于“业务”，或者说我们的数字系统的建模对象

而发明眼花缭乱的技术、思想，什么 react programming/DDD/各种 design pattern ，不过是为了控制复杂度的实践而已

不要搞反了关系，如果你预期到你的建模目标的复杂度不值得你专门去搞一个新“技术”/“框架”，那你就不用嘛

虽然我也问过类似的问题，但就冲说出 “非常耗费资源的操作”， 这面试官水平就不怎么样，什么叫消耗资源，啥资源啊

用 C++ 写, 使用 imGUI 这样的 Immediate Mode 方式绘制, 然后编译到 wasm/webgl

@thevita 现在还多一种，有时一些突然的观点，也发给 ChatGPT/DeepSeek ，当作思维发散器用

有一种磕巴是，想得太多，俗称脑子比嘴快，尝试文字输出行不行，如果文字没问题（即便慢点），那就是这种。

那就看说话的目的了，a) 即兴演讲、公开讲话，这时不犯错比说得出彩重要，讲得多就整理出来了一套自己的话语，用的时候，适当组合下，就尽量不输出即时的观点，b) 讨论、辩论、会议，慢一点，思考一下没什么不好，只要不是吵架。

总的来说，还是要多输出，通过输出来驱动对信息的整理、压缩。

我现在没时间（其实是懒），就直接写到 notes 里面，想到就记忆段，有时候看到就整理下

这个问题吧: https://go.dev/blog/loopvar-preview

具体来说, golang 在 loop 的行为在 1.22 之后变了

cpu time 采样有 call stack, 但采不到 goroutine, 要能在 profile 上看到特定 goroutine 的信息, 要么让 某个 callstack 只跑一个 goroutine, 要么让特定的任务的 callstack 不一样，比如让某个 http 请求多一个特定的 middleware

天，但凡你多翻翻呢

- app store 上大部分进入维护阶段的 app, changelog 基本都是没啥实际意义的话
- 曾经 app store changelog 也被用作某种传播（亚文化），比如 bilibili
- app store 要更新一些描述啊，截图啊，只能发一个新版本
- 至于维护阶段的 app 为啥这么敷衍，只要你维护过时间长一点的代码，应该能理解，相当多是很难直接能被用户感知的更新，写上去还得费劲跟用户解释

管理 本地工具链吗？, asdf 啊

提供一点信息: https://www.volcengine.com/docs/82379/1346560

火山引擎好像是要手动管理 cache 的，大概看了下，好像没说 completions 会自动给 prefix cache ，未验证，仅提供方向，看看 你 api 的 usage 有没有命中咯

本质就是 小程序不想让你操作 DOM, 只提供封装后的给你, UI 的实现就可以有私有实现（比如 暴露一些 wx 内部的 API/控件 什么的出去）

浏览器为什么不这么设计: 因为原来没有这样的需求

这里 独立的 JS 线程 就是 个 没有 web api javascript instance （因为所谓的 “多个线程同时修改 DOM ，可能会导致竞态条件和不可预测的结果”，就是 web api 不提供线程安全性），现代 web 浏览器里也是有的，就是 Web Worker ，

只是小程序，的与 UI 线程的通信/交互啊什么的都是封装好了的，Web Worker 里你得自己来

我怎么感觉 “现在为了 k8s 集群部署，就把服务拆分出去，每个服务一个单独的仓库。” 这里槽点最大啊

代码组织方式应该是服务于开发团队的协作方式的，而不是紧急为了在 k8s 上部署（就是所有代码都在一个仓库里也不是就不能在 k8s 上部署了啊，无非就是 google 搜不到而已..，看不懂）就这么大动干戈的让所有人去适配机器，，，

所有方法都重写成:
sql.execute(
openai.chat.completions.create(, message=["hey, here is my parameters: {paraMap}, funcName: {funcName}, dbSchema={dbSchame}, how can I query data. give me sql"])
)

因为综合评价一个人的能力真的挺难的，至少得约出来聊几次吧，还需要聊的人比较会聊，但这会带来新的问题，即人给予个人经验的评价一定是带有偏见的，对于 hr 来说，机遇学历的评价就是一个极具性价比的手段