能否将Server Actions作为SWR Fetcher使用？该方案是否最优？

我想了解把Server Actions作为SWR的Fetcher是否是最优方案，目前没找到相关官方文档说明。实际测试中发现这个方案体验很好——同一个Server Action既能在服务端组件直接调用，也能在客户端组件通过SWR使用，还能保持完整的TypeScript类型支持，比如下面的示例：

示例：获取当前用户信息的Server Action #

actions/whoami.ts

"use server";

import { auth, prisma } from "@/lib/auth"; // next-auth配置文件

export default async function whoami(): Promise<User | null> {
    const session = await auth();

    if (!session?.user || !session.user.email) {
        return null;
    }

    const user = await prisma.user.findUnique({
        where: {
            email: session.user.email,
        },
    });

    return user;
}

在客户端组件中使用

export default function ClientPage() {
    const { data: user } = useSWR("whoami", whoami);

    console.log({ user }); // user类型完全匹配
    return "...";
}

在服务端组件中使用

export default async function ServerPage() {
    const user = await whoami();

    console.log({ user }); // user类型完全匹配
    return "...";
}

这个方案的优势很明显，但为什么Next.js或SWR的官方文档里没有相关说明？

这个方案的优劣分析 #

优势

• 复用性拉满：无需额外编写API路由，同一个Server Action可以同时服务于客户端（借助SWR的缓存能力）和服务端组件，减少重复代码
• 类型安全无额外成本：从Server Action到组件使用全程保持TypeScript类型推导，不用手动定义API返回类型或做类型转换
• 内置服务端逻辑：Server Action本身运行在服务端，权限校验、数据库操作等逻辑可以直接写在里面，不用在API路由里重复实现
• 享受SWR的生态能力：自动缓存、窗口聚焦重新请求、错误重试、缓存失效等SWR自带的特性，都能直接和Server Action结合使用

局限性

• 请求方式差异：Server Actions在客户端调用时本质是POST请求，而SWR默认的缓存策略更适配GET请求，复杂场景下需要手动配置SWR的缓存key和请求选项
• 跨库组合的兼容性：Server Actions是Next.js专属特性，SWR是独立的数据缓存库，两者的组合属于社区实践，版本迭代时可能存在兼容性细节需要留意
• 动态参数处理：如果Server Action需要接收参数，需要确保SWR的缓存key和参数严格对应，否则容易出现缓存混乱的问题

为什么官方文档没有相关说明？ #

1. 官方侧重基础场景：Next.js文档优先介绍Server Actions的核心用法（比如表单提交、数据修改），SWR文档则更偏向配合标准API路由的使用，这种跨库组合的进阶用法不在基础文档的覆盖范围内
2. 社区实践优先：这类组合用法通常是社区开发者摸索出来的，官方可能需要观察社区的使用反馈和稳定性，再考虑是否纳入官方文档
3. 场景适配性问题：并非所有场景都适合用Server Actions作为SWR Fetcher，比如需要公开访问的API、复杂的RESTful接口等，官方可能不希望过度推荐某一种特定组合，避免限制用户的选择

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