从 React SPA 迁移到 Astro：何时迁移以及原因
问题并非 React 本身
React SPA 在构建时有其合理之处：团队熟悉它，生态系统成熟，组件模型与设计系统配合良好。问题不在于 React，而在于 SPA 架构与内容驱动网站目标之间的不匹配。
企业网站需要快速加载、良好的 SEO、可预测的爬虫行为，以及不依赖 JavaScript bundle 大小的性能。SPA 在这些方面天然处于劣势。
触发迁移的指标
Core Web Vitals 是第一个警示信号。LCP 分数持续落入需要改进区间，不是因为服务器慢，而是因为在 JavaScript bundle 执行完成之前，浏览器没有任何内容可以渲染。
第二个信号是 SEO 抓取报告。尽管 Googlebot 确实执行 JavaScript，但抓取延迟和索引一致性问题意味着新内容需要数周时间才能稳定出现在搜索结果中。
为什么选择 Astro
Astro 的孤岛架构正是这类用例所需要的：默认静态 HTML，对交互式组件按需注水。对于主要是内容页面的企业网站，这意味着大多数页面根本不需要客户端 JavaScript。
迁移路径也比预期的更加渐进。Astro 可以导入现有的 React 组件，这意味着我们可以先迁移路由和页面结构，再处理具体的组件。
实际迁移
我们从路由结构开始：在 Astro 中重建页面层次结构，将 React 组件直接导入为 Astro 孤岛。性能提升立竿见影——LCP 分数在第一批页面迁移后从需要改进跃升至良好。
完整迁移历时约六周，包括重建博客系统（从基于 API 的内容获取改为 Astro 的内容集合）以及更新部署流水线。
值得注意的权衡
交互式功能需要更多思考。需要状态的组件必须明确标记为客户端孤岛，这在初期会造成一些摩擦。团队需要转变思维方式——默认不是一切都是 JavaScript，而是除非有理由否则默认是 HTML。
从长远来看，这种转变是积极的。它迫使团队更有意识地决定哪些内容真正需要客户端交互性。