最近我们把知识库发出来了，所以相对空了一点，不用每天爆肝了。然后就扫了扫论坛里大家对 LobeChat 的很多讨论，和我之前的以为的还是有挺多差异的。
所以准备发一个 AMA（ Ask Me Anything） ，大家可以问任何对 LobeChat 感兴趣的问题或者疑问，可以在这里问我~
哈哈哈 佬友真强, 我想问一下为啥 lobechat 选择了 SSR 的架构, 而不是类似于静态的单页应用这种? 感觉如果是单页应用 PWA 也会很快啊 有时候卡了一些, 最近更新之后好像好了一些, 打开设置没那么卡了
39 个赞
太强了大佬
非常需要高质量RAG！
不太了解LobeChat!
67 个赞
前排等，谢谢分享
24 个赞
除了文本多了很卡以外，其他都很好，有没有办法优化的，经常贴代码
18 个赞
为啥 lobechat 选择了 SSR 的架构, 而不是类似于静态的单页应用这种
说实话，其实我一开始选的时候并没有纠结 SPA 还是 SSR，只是单纯想试试 Next.js 而已。因为以前我自己的搞的项目都是用的 Umi.js 一把梭。然后 Next.js 在国外这么火，就想试试看。
因为 Nextjs 默认是 SSR 的，所以也就跟着 NextJS 的规范来搞了。然后后面其实看到 NextChat 的实现以后才知道原来 Next 也可以自己套一层当 SPA 用 
不过这是后话了。
但如果从今天来看，再让我选的话，我估计还是会选现在的方案，Vercel 和 React 他们的技术路径我觉得是非常对的。
具体展开来讲：
-
SEO 优化。这一点其实是 SSR 的强项，也是毋庸置疑的。LobeChat 也好，我们的官网也好，都需要从搜索引擎获得流量，SSR 的方案是最理想的，而且目前看下来的效果也还 OK 。
-
SSR 能带来更好的首屏感知。这个是我作为设计师的执念，一般 SPA 的首屏最多加个 load 就完事了，但是通过 SSR + 水合的方式，能做到首屏直出应用的完整骨架屏，带来更小的 CLS 。
以 LobeChat: Your personal AI productiv... · LobeChat 为例，SSR 首屏直出是这样的：
甚至你如果点 devtools 去看的话，首屏返回的 html 直接是数据 loading 的样子。
这就意味着当服务端返回给你 html 时，用户看到的就是已经等待加载数据的样子了。而如果换到 SPA 的话，这个骨架屏要等到 JS 加载完之后才能出现。
- 在 SSR 之上，新的 RSC 带来了更强的服务端渲染能力，能带来更好的移动端首屏体验。具体细节不展开了，可以看当时写的 [RFC] 002 - Pref Mobile 移动端 FOUC · lobehub/lobe-chat · Discussion #252 · GitHub 这个RFC。
上面这个就是从 SSR Layout 切到 RSC Layout 之后带来的性能提升，因为只用加载一套移动端 layout 的 js ，bundle 一下子就小了很多。而 SSR还是要同时带上pc的和移动的 js。
- 基于 RSC + Feature Flag 可以轻松实现不开启的页面功能完全不可用。通过 RSC 模式下+ 服务端 Feature flag ，可以用几行代码就能实现页面级别的隐藏。比如我加一个
Feature Flag=-knowledge_base， 那么/repos的页面直接返回404。SPA 应该是没有能力做到这一点的。
import { notFound } from 'next/navigation';
export default ({ children }: PropsWithChildren) => {
const enableKnowledgeBase = serverFeatureFlags().enableKnowledgeBase;
if (!enableKnowledgeBase) return notFound();
return children;
};
- 在网络加载比较慢的场景下（包括本地启动慢），Next 的平行路由能力可以使得最重要的 children 部分（即对话区）优先渲染出来，并且可以提前开始交互。
这个细节估计很多人都意识不到，但我自己在本地开发的时候已经发现了很多次了。一开始我以为是偶然的，但是通过大量重复复现发现真的是这样。然后去看 react/next 的文档才发现这个就是 react 这些年在推崇的 Suspense + Stream 带来的特性。而这个特性应该也只有在 SSR 场景下才能启用。这个说实话是真的很细致的点了。
所以为了更好的用户体验的上限，我觉得用 SSR 和 RSC 才是正解。
50 个赞
这个算是一个已知问题了。
原因是我们会在界面上实时计算当前消息的所用 token 数。
为了力保计算准确， 这个功能在实现上，会使用一个重计算的 wasm 模块 gpt-tokenizer，用于将字符串计数成 token （这个包也非常大）。
目前的实现中， tokenzier 是在主进程跑的，短上下文还好，但如果你的上下文很长，这个计算耗时就不可忽略了。
我之前测试时，当 token 数量达到 10k+ 级别时，单次 token 的计算耗时会达到几百毫秒，会有肉眼可见的延迟。
后续的优化方案就是将其挪到 Web Worker 进行异步处理，不阻塞主进程，那么这样就不卡了。
相关问题：
17 个赞
我回头看看，可能是 bug
14 个赞
我使用的时候发现，上下文较长的时候(大概8wtoken以上)，边输出文字边滚动聊天框会十分卡顿，这时候只能等输出完了再去滚动查看上面的聊天记录，很不方便。
同时还有就是问了问题之后，我切换到其他网页窗口，这时候不会继续输出文字，只有放在前台才会持续输出文字。
上面两点用久了实在不舒服，长文本的时候需要等待的输出时间也长，只能放在前台等输出完。
(大概一个月前还在用，最近没怎么用，不知道最近效果如何)
15 个赞
迁移到服务器数据库版 , docker部署+neon+ github +Cloudflare R2 ，浏览器占用稳定在1g 上下了 ,这组合服务器也不需要启更多服务，好用 
24 个赞
太强了大佬！
17 个赞
这个就是我说的计算那个问题，流式输出的时候也会实时计算 token 用量。这个后续会优化的
15 个赞
太强了大佬
12 个赞
nexo 是啥
6 个赞
其实1G在我看来也是有点高… 我自己日常使用就 300~500M 这样
27 个赞
的确… 40k token 应该也会有上面说的问题…
我自己日常使用其实会把上下文控制到 10k 以内，这样相对来说性价比是最高的。
20 个赞
打错了123
15 个赞