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

webeasymail 2026-08-14 17:30 1

最近一段时间一直在做 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 改写,很多东西也会有问题。

最新回复 (8)
  • webeasymail 楼主 08-14 17:34
    1
    有熟悉 CF 的大佬,请赐教一下,真不明白这么简单的工具为什么老是有这种问题,我之前开发的工具都是使用 next.js 但是都是使用客户端导出的模式,所以加载速度快,也没有遇到这个问题,因为这个是 SEO 站点,所以不太想使用 next.JS ,主要是 NEXT.JS 的前后端混合有时候使用也挺无语的,然后 next.JS 的国际化感觉也不太好用。
  • webeasymail 楼主 08-14 17:35
    2
    我原本是做 JAVA 这块的,前端是去年开始学习的,主要是靠 AI ,实际上特别底层的东西有时候感觉理解的不透彻,虽然能够用,但是不通透。
  • webeasymail 楼主 08-14 17:42
    3
    我很想知道 astro 是不是会更好,不知道有没有做这种 seo 站点使用 astro 的。
  • coderfee 08-14 17:53
    4
    免费版本身就有 cpu time limit https://developers.cloudflare.com/workers/platform/limits/#cpu-time ,但我用的 astro 和 tanstack 基本没遇到过。
  • helloet 08-14 18:06
    5
    用 tanstack 全家桶呗,比 nextjs 体验好很多
  • webeasymail 楼主 08-14 18:07
    6
    @coderfee tanstack 这个好用吗? tanstack 当时也考虑过,不过对 tanstack 这个更不熟悉,就没有敢使用,免费版是有的,但是 https://bataitools.com 这个可以说是完全没有什么业务的系统,执行速度是很快的。
  • webeasymail 楼主 08-14 18:21
    7
    @helloet 那我高低的尝试一下 tanstack ,之前一直使用 NEXT.JS ,我是真心不喜欢 next.js 什么客户端/服务端模式的写法 真的要命,写的我都怀疑回到 JSP 时代了。
  • webeasymail 楼主 08-14 18:59
    8
    果然还是要多反思,在反思的过程中,突然发现既然是 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 。
* 帖子来源V2EX
返回