Next.js 的 Server Actions 顾名思义是在服务器端执行的函数。这意味着可以将数据获取和更改等功能交由它们实现，而且不存在从客户端获取和更改数据所带来的漏洞和安全问题。
要充分理解 Server Actions，就必须了解它们解决了什么、我们之前是怎么解决这些问题的以及它们的演变史。我们将在本篇文章中深入探讨所有这些方面。但首先，让我们从头开始。
Server Actions 的历史
这一历程始于 PHP 中的服务器端渲染 (SSR)。数据获取、更改和 CPU 密集型任务都是在服务器上进行的，因此浏览器只能向用户显示轻量级的渲染页面：
这意味着每次用户导航时都需要再次执行下列任务: 向服务器发送请求，生成页面，然后发送到客户端。用户每次都要等待这一过程完成后才能看到页面并与之交互，很麻烦不是么。
下一次技术迭代：客户端渲染 (CSR)。如果我们让客户端来处理导航，而不是每次用户导航时都向服务器发送一个新请求会怎么样呢？
这意味着服务器在第一次响应时，就会向客户端发送渲染代码。这样，客户端就能在用户浏览网站时处理页面渲染：
通过 CSR，我们解决了 SSR 带来的一系列数据往返问题，实现了更快和反应更灵敏的页面转换。但我们也给自己带来了一个新问题：
当服务器向浏览器发送 JavaScript 时，搜索引擎无法正确索引网站，因为网站的实际 HTML 还没有完全形成。浏览器必须先从服务器下载并执行 JavaScript，然后对页面进行水合处理，以形成网站的完整标记。
这就是静态网站生成 (SSG) 的由来。这是实现更快页面加载和搜索引擎优化标记的最新技术，我们的想法是将 CSR 和 SSR 的优点结合起来，在构建时在服务器上预先生成网站的所有页面。
构建脚本或静态网站生成工具会处理源代码和内容，为网站上的每个页面生成静态 HTML 文件：
构建过程还可能涉及从各种来源（如 API 或数据库）获取数据，并渲染静态 HTML 页面。但是，如何处理动态内容更新和实时数据是一个问题。SSG 可能并不适合所有类型的网站，但是有了 React Server Actions。
React Server Components and Actions
从 SSR 到 CSR 再到 SSG 的旅程中，有一点是肯定的：没有放之四海而皆准的解决方案。而 React Server Component （RSC），为开发人员提供了一个灵活的选项。
有了 Server Actions，您现在就可以这样说了： “XYZ 组件应仅在服务器上执行，而 ABC 组件应在客户端执行"。React Actions 实现了这一功能，而 Next.js Server Actions 正是基于这一概念构建的：
Server Actions 在 Next.js v14 中引入，是编写指定在服务器或客户端执行的函数的一种方法。这让数据获取和更改等方面更灵活便捷。
Next.js 中 RSC 与服务器行为的结合意味着我们有了一种更好的方式来考虑数据获取。以前，我们获取数据的方式多种多样。
例如，可以使用 useEffect 钩子获取数据并管理加载状态。还可以使用 GetStaticProps 和 GetServerSideProps 进行页面级数据获取。当需要使用敏感凭据进行数据库调用时，可以设置 API 路由并在其中定义函数。
现在，有了 RSC 和 Server Actions，就更容易理解了。每个组件都可以获取自己的数据，并且可以在组件内直接进行更改，从而减少了对外部 API 路由的需求：
