Cloudflare 前端 NEXT.JS 还是 REMIX 还是 ASTRO

webeasymail · 发表于 2026-8-14 17:30:09

最近一段时间一直在做 https://bataitools.com/ 然后部署在 Cloudflare ，中间一直遇到 CPU LIMIT 的问题，说一下历程，这个问题也有点让我无语，毕竟是这么简单的一个小导航站。

1 、最开始我是 NEXT.JS （由于有动态 URL ，所以当时使用了是服务端模式），然后使用 OpenNext 总是遇到 CPU LIMIT （我后来怀疑是我没有配置好，或者部分代码写的不太好导致，可惜架构已经切换了）。

2 、通过和 AI 沟通，因为代码已经很多，推荐切换到 React Router 7 ，最后发现还是有 CPU LIMIT 。

3 、开始优化数据库查询性能，创建索引，减少查询复杂度，引入 cache ，结果发现还是偶发 CPU LIMIT 。

4 、最后在前端加入了一个自定义的 edge cache ，确实好了很多，基本上没有 CPU LIMIT ，但是感觉这怪怪的，而且首页会偶发 CPU LIMIT 。

5 、终极方案，首页内容多，查询条件多，直接使用定时任务跑 cache ，首页直接拿 cache 就好了，这个时候真的基本上没有啥问题了。

6 、最后发现在某一些页面还是有 cpu limit ，最后发现是动态加载元数据导致，然后把 react router 的配置修改为 routeDiscovery: { mode: 'initial' }, 但是页面会增加 19kb 的内容（压缩以后得）。

7 、最后把页面的 CDN cache 打开，缓存 5 分钟，基本上没有 cpu limit ，但是会在摸个时间突发 cpu limit ，在这个时间会看到后台有很多 cpu limit 的错误。

我的网站实际上很简单，什么鬼业务都没有，我还真不知道为什么会出现这种问题，不知道免费的是不是就这样。

有熟悉的小伙伴出现评论一下，你们都使用啥框架呀？这个问题前前后后感觉折腾也挺长时间了，如果整体换 Astro 感觉最好，但是换 Astro 代码要完全重构了，涉及的东西也挺多，就算 AI 改写，很多东西也会有问题。

webeasymail · 发表于 2026-8-14 17:34:50

有熟悉 CF 的大佬，请赐教一下，真不明白这么简单的工具为什么老是有这种问题，我之前开发的工具都是使用 next.js 但是都是使用客户端导出的模式，所以加载速度快，也没有遇到这个问题，因为这个是 SEO 站点，所以不太想使用 next.JS ，主要是 NEXT.JS 的前后端混合有时候使用也挺无语的，然后 next.JS 的国际化感觉也不太好用。

webeasymail · 发表于 2026-8-14 17:35:46

我原本是做 JAVA 这块的，前端是去年开始学习的，主要是靠 AI ，实际上特别底层的东西有时候感觉理解的不透彻，虽然能够用，但是不通透。

webeasymail · 发表于 2026-8-14 17:42:50

我很想知道 astro 是不是会更好，不知道有没有做这种 seo 站点使用 astro 的。

coderfee · 发表于 2026-8-14 17:53:50

免费版本身就有 cpu time limit https://developers.cloudflare.com/workers/platform/limits/#cpu-time ，但我用的 astro 和 tanstack 基本没遇到过。

helloet · 发表于 2026-8-14 18:06:37

用 tanstack 全家桶呗，比 nextjs 体验好很多

webeasymail · 发表于 2026-8-14 18:07:55

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

webeasymail · 发表于 2026-8-14 18:21:04

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

webeasymail · 发表于 2026-8-14 18:59:41

果然还是要多反思，在反思的过程中，突然发现既然是 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 。