✅ **技术选型差异：网页应用 vs. 网站** - 文章开篇点明，为项目构建的“网页应用”（如 PigeonPod Web App）与为吸引流量和展示信息而设计的“网站”（落地页）在技术需求上存在本质区别。作者最初基于熟悉的 React + Mantine UI 构建落地页，获得了不错的 Lighthouse 性能评分，但忽视了搜索引擎爬虫对动态渲染内容的处理能力，导致网站在 Google 搜索中无迹可寻，深刻体会到为“网站”而优化的必要性。

🔄 **Next.js 的平台绑定：Vercel 依赖性** - 在意识到需要服务器端渲染（SSR）或静态站点生成（SSG）后，作者转向了 Next.js，但很快发现其许多核心功能，特别是图片优化，与 Vercel 平台深度绑定。尝试 OpenNext 和静态导出等方案均遇到“坑”，浪费了大量时间，作者认为 Next.js 在很大程度上是 Vercel 的“全家桶”，选择它意味着选择平台，这对于希望部署在其他平台（如 Cloudflare）的用户来说是一个重要的考量点。

⚙️ **Astro 的生态兼容性：CSS-in-JS 的挑战** - 寻求更自由部署的作者转而尝试 Astro，因其默认 SSG 和支持 React 组件的特性而备受吸引。然而，在迁移代码后，Astro 与 Mantine UI 等 CSS-in-JS 库的兼容性问题成为了新的障碍，官方文档明确表示不支持。这暴露了 Astro 在性能至上的同时，对某些 UI 库生态存在不友好的情况，作者在此认识到框架在实际应用中的具体限制。

📢 **“无缝迁移”的警示** - 通过这次前端框架的探索，作者对“无缝迁移”这一营销口号表达了深刻的怀疑。他认为这更多是一种诱人的宣传语，在实际操作中往往伴随着大量的挑战和适配工作，不应被轻易相信。实际迁移过程需要深入理解不同框架的哲学、设计理念以及生态系统的运作方式，才能做出明智的技术选择并有效规避风险。

兄弟们，是这样的，我原本是一个 CRUD 仔，最近做了个开源项目 PigeonPod 得到了不少朋友的喜欢。我就趁热打铁搞了个时髦的 Landing Page，结果在前端这块被结结实实地上了一课，想分享一下踩坑血泪史，希望能帮同样是后端背景的兄弟们省点时间。

故事是这样的：

开局： 我用的是典型的“稳重派”，技术栈直接选了生态最强的 React + Mantine UI。心想这套搞熟了就能一招鲜吃遍天，PigeonPod 本体的 Web App 就是这套技术栈做的，用得很舒服。我就同样把代码改吧改吧直接做了 Landing Page ，很快做完上线，看着 Lighthouse 的 performance 92; Best Practices 100; SEO 85 的评分，感觉稳得很。转折： 一个月后，Google 上压根搜不到我的网站。这才被迫搞明白，我那套 pre-render 小伎俩在真爬虫面前就是个笑话，必须上真正的 SSG 。第一劫：Next.js 。 都说它是 React 的“亲哥”，无缝迁移。结果呢？花了好几个小时迁过去，准备部署到 Cloudflare 的时候才发现，这玩意儿跟 Vercel 是深度绑定的，图片优化之类的核心功能离了 Vercel 就废了。感觉自己被“PUA”了。试了 OpenNext 、静态导出，全都是坑，又浪费了大半天。第二劫：Astro 。 痛定思痛，决定换个思路。Astro 看起来简直是梦中情“框”：默认 SSG 、能用 React 组件、部署自由。结果呢？兴冲冲地把代码迁过去，一编译就报错。最后在官方文档里找到一句冰冷的 “Not a chance” —— Astro 和所有 CSS-in-JS 的 UI 库（比如我用的 Mantine ）八字不合。

前前后后快两天时间，代码没写几行，算是把前端这些框架的哲学和门派给彻底搞懂了。

最后悟出几个道理：

做“网页应用”和做“网站”是两码事，技术选型完全不同。Next.js 是 React 的 “全家桶”，但它更是 Vercel 的 “全家桶”，选它等于选平台。Astro 性能至上，但对某些 UI 库生态不友好。“无缝迁移”这四个字很诱惑，但是听听就好，都是营销口号，别当真。

把整个心路历程和技术上的思考都写成了文章，里面有更详细的踩坑细节和“暴论”，希望能帮大家看清前端这个“花花世界”。

博客原文链接在这儿: https://asimov.top/posts/react-vs-nextjs-vs-astro-for-backend-devs