webeasymail

优化到最后还是不行，因为使用了 SSR ，cf 上面 ssr 平均是 10 ～ 20ms ，我已经优化到 10ms 一下，直接转为付费的，在观察一下成功率，free 的依然有 3% 的失败率。

@nomisk computer 没用过，主要就是 worker ，文件读写我都使用对象存储存的，而且 worker 后端有严格的时间限制，对于前端 ssr 请求时间也限制很严格。不过大部分都可以服务拆分解决，最关键付费版限制会松很多。

牛掰，如果+协作功能就更好了

@zjason 一句话就可以免费收录 cun.ai ，无需交换链接，无需审核，AI 自动审核 ，可以尝试一下 ,搞不好能够给你带来几个访问量。https://bataitools.com/zh/submit

@iyuanyi 你想换也可以呀，不过提交是不用换的，换链接主要是赞助.

不用审核的，agent 自动发布的。

果然还是要多反思，在反思的过程中，突然发现既然是 SSR 导致的问题，那么我直接把 HTML cache 不就好了，于是自定义一个 woker cache （主要解决不同参数使用同一个缓存的问题） + 全站 CDN ，这样也可以不去触发 SSR 了。


错误原因：
为什么一张表单会打满 CPU
Worker 并不是在「渲染一个表单」，而是在跑 整站 SSR 壳：

root.loader：加载并 activate 印地语词包
entry.server.tsx：再 activate 一次，然后 renderToReadableStream
AppThemeProvider：MantineProvider + Modals + Notifications + next-themes
handshake layout：GoogleOAuthProvider （忘记密码根本用不到）+ LanguageSwitcher （ Mantine Menu ）+ 28 条 hreflang
表单：@mantine/form 、PasswordInput 、Turnstile 、Background
Cold isolate 上，光求值 Mantine + Lingui + React 19 就可能超过默认几十毫秒 CPU 。页面逻辑不重，共享模块图太重。

from=/hi/tags/paid/page/2 只是回跳参数，不是根因。印地语只是碰巧被打到的 locale 。

@helloet 那我高低的尝试一下 tanstack ，之前一直使用 NEXT.JS ，我是真心不喜欢 next.js 什么客户端/服务端模式的写法 真的要命，写的我都怀疑回到 JSP 时代了。

@coderfee tanstack 这个好用吗？ tanstack 当时也考虑过，不过对 tanstack 这个更不熟悉，就没有敢使用，免费版是有的，但是 https://bataitools.com 这个可以说是完全没有什么业务的系统，执行速度是很快的。