带Mutation的Server Action能否传给客户端组件及Lint疑问

问题1：为何规则取决于Mutation？带Mutation且调用revalidatePath的Server Action能否从服务端组件传给客户端？ #

规则依赖Mutation的原因 #

Next.js对Server Action传递的限制，核心围绕数据操作的安全性和状态一致性：

• 无Mutation的只读Server Action：这类操作只负责从服务端查询数据，不会修改任何持久化状态。就算客户端多次调用，也不会引发数据冲突或状态不一致的问题。传递给客户端的只是一个远程调用的引用，实际执行逻辑全程在服务端，所以Next.js允许这种场景。
• 带Mutation的修改类Server Action：这类操作会改动服务端数据，直接传递给客户端时，Next.js的设计逻辑会担心开发者忽略潜在风险——比如重复提交、未正确配合revalidatePath处理缓存失效、或者疏忽了服务端权限校验（虽然实际执行仍在服务端，但Lint规则会提前给出预警）。

带Mutation且调用revalidatePath的传递可行性 #

完全可行，而且**getServerSession可以正常调用**。
要注意区别两种场景：

• 如果在客户端组件中直接导入Server Action，Action代码会被打包进客户端 bundle，此时getServerSession作为服务端专属API，必然报错；
• 如果是从服务端组件将Server Action作为props传给客户端组件，客户端拿到的只是一个远程调用的入口，实际执行逻辑全程在服务端，所以getServerSession能正常获取会话信息，revalidatePath也能正常触发缓存更新。

问题2：为何传递带Mutation的Server Action给客户端时会出现Lint警告（运行时正常）？ #

这是Next.js内置ESLint规则（比如@next/eslint-plugin-next/no-server-actions-in-client-components）的保守设计导致的：

• 该规则的核心目的是提前规避潜在风险：它默认会限制客户端组件直接使用Server Action，哪怕是通过props传递的场景——因为修改类操作可能存在重复触发、未处理乐观UI、权限校验遗漏等隐患。
• 但从运行机制来说，从服务端组件传递的Server Action本质是远程调用，执行逻辑仍在服务端，所以不会有运行时问题。Lint警告只是规则的预防性提醒，你可以通过添加单行注释（比如// eslint-disable-next-line @next/eslint-plugin-next/no-server-actions-in-client-components）忽略该警告，或者在ESLint配置中针对特定场景调整规则。

内容的提问来源于stack exchange，提问作者Florian Walther