如果你不介意的话，可以和我交流下，我也想接触一些 iOS 方面的知识和经验。

将来.

你的项目有将来吗?
你的公司有将来吗?
你在你这个公司有将来吗?

这是综合下来整体成本最低的一种方法了。

要不然我就得去实体店。
要不然我就买一件，试了不行，退一件，再来，再退，一次退货改成多次退货，多用物流资源。

试衣服的试这个字的成本，总得有人承担。
一次多件，就是综合下来成本最低的方法了。

你就当成是下一个 Spring Boot+ Vue in china 的地位就可以了。

说人话就是纵使它有千般不好万般不是，你还是只管冲就对了。

对了，我卖 Next.js 的课的。XD

以及，大小写正确好评。

@codehz 谢谢啦，我也发现了这点。正在换方案。

@modao526 应该不至于……

@ddosakurax 对，langchain 使用的是 duck-duck-scrape ，它底层是 xmlhttprequest ， 但是在 cloudflare 上不支持，它家的 worker 只支持 fetch ，所以我才改了下。

主要是给一些个人项目需要白嫖的时候可以用用。

升级到 14.1.2 ，通知中心卡死再也打不开了。notification center 进程还 99.9 CPU 掉不下来，网上一搜虽然不普遍，但只要出现了这个问题的都还没什么完美解决办法。

Gen 系列除了贵其实我觉得没什么缺点

作为主功能来说确实不是很适合，但作为非主业务的补充，一些边缘化的事情，写进主单体或者部署个微服务反而头疼，如果正好用量占比又不大，云函数我觉得非常合适，我自己就有大概二三十个类似的云函数。

它们有一些共同特征，本身逻辑简单，没太多状态，放进哪个仓库或者服务都觉得不是很符合语义或者模块划分，单起个又恶心，这个云函数的服务本身甚至可有可无，也许只是个实验特性，这一类我现在优先会选择用个简单的云函数快速跑起来，先满足了业务需求再说。

当然云函数也有一些问题，本身写起来如果依赖的东西多，放云函数里跑限制一堆，很麻烦，数量也很容易暴涨。但数量保障我觉得就是没规划好，说明不是一些适合放到这里面的服务。

我大概二三十个，有的一两年前的我都快忘了代码了，真要更新迭代我十有八九不会去修改这个云函数，而是去直接快速重写一个，很大可能一天内就搞定了。这也是我会把云函数用的地方，有一些属于不需要长期更新迭代，但会长期使用的轻量级业务，我都会扔进去。

而一个足够大型的系统，十有八九总能找到这样一些类似的边缘的业务。当然要不要上云函数那是见仁见智。

我这周才刚又写了一个近似于采集系统的东西，非典型业务，不适合抽象起来放进现有架构，又急需，以后又基本没什么更新，用量不大，一天目测就几百次调用，这种我就是一天写完，一天测试，丢上去完事。

过几个月也许有迭代了再说，大迭代就重写拉倒。

我个人目前在用也是我推荐的方式其实是 LangPilot ……

但事实上我真正主力依赖的还是 GitHub Copilot 的那些东西。Copilot 和 Chat 类不一样，最大的难点我觉得不是在 server 端或者说 LLM ，而是在 client 怎样更好的构建上下文，理解不同窗口和 tab 的关系，理解文件夹树，理解项目结构，这些在端侧构建的东西的好坏极大程度影响 copilot 的质量。

go 。

我 30 分钟就不行了

干活用 fastapi ，找情怀用 flask ，玩用 sanic 。

yet another awesome

我当年提类似问题的时候，一堆人纷纷教育我说我使用电脑的姿势不对。

我拍照截图给出当时 ThinkPad 某款的设计，圆弧的角，无论是手腕还是手臂搭上去都很舒适，一群人纷纷选择无视。

现在可能都快十年过去了吧，这个问题对我这种人依旧存在。

我仍然有最新的 MacBook ，但我永远唾弃这个设计。

我认为恰恰是楼主想提供更好的方式和体验，才试图找到更好的方法来优化。
而不是像有的人说的很搞笑，花不花钱，提供商在不在乎。

不使用 react-router ，使用状态管理如 zustand 之类，把数据获取和对数据的二次加工等放进去也是个不错的选择。