本文详解如何在 Next.js 13 的混合渲染环境中（Client Component 与 Server Component 共存）正确读取 authToken 等关键 Cookie，避免因错误导入 next/headers 导致的构建失败，并提供可复用、类型安全的 myFetch 封装方案。
本文详解如何在 next.js 13 的混合渲染环境中（client component 与 server component 共存）正确读取 `authtoken` 等关键 cookie，避免因错误导入 `next/headers` 导致的构建失败，并提供可复用、类型安全的 `myfetch` 封装方案。
在 Next.js 13+ 的 App Router 架构中，next/headers 是纯服务端模块，仅可在 Server Components、Server Actions 或服务端路由处理器（如 route.ts）中同步使用。一旦在标记为 "use client" 的组件或其调用链中直接 import { cookies } from 'next/headers'，就会触发你遇到的编译错误：
You're importing a component that needs next/headers. That only works in a Server Component...
根本原因在于：next/headers 依赖 Node.js 运行时上下文（如 Headers 实例和请求生命周期），而客户端环境（浏览器）完全不具备该上下文。因此，不能通过条件判断 typeof window === "undefined" 后静态导入 next/headers——ES 模块的 import 语句必须在模块顶层静态解析，无法按需加载。
✅ 正确解法是：动态导入（Dynamic Import）。它支持运行时按需加载模块，且 Webpack / Turbopack 会自动将其分离为独立 chunk，确保服务端代码不会被打包进客户端 bundle。
以下是经过生产验证的 myFetch 封装实现：
// utils/myFetch.ts
const myFetch = async <T>(...args: Parameters<typeof fetch>): Promise<T> => {
let token: string | undefined;
if (typeof window === "undefined") {
// ✅ 服务端：动态导入 next/headers（仅在 Node.js 环境执行）
const { cookies } = await import("next/headers");
const cookieStore = cookies();
const authCookie = cookieStore.get("authToken");
token = authCookie?.value;
} else {
// ✅ 客户端：动态导入 js-cookie（仅在浏览器环境执行）
const { default: Cookies } = await import("js-cookie");
token = Cookies.get("authToken");
}
// 构造带认证头的请求配置
const [url, options = {}] = args;
const headers = new Headers(options.headers || {});
if (token) {
headers.set("Authorization", `Bearer ${token}`);
}
try {
const res = await fetch(url, {
...options,
headers,
});
if (!res.ok) {
throw new Error(`HTTP error! status: ${res.status}`);
}
return (await res.json()) as T;
} catch (err) {
console.error("myFetch failed:", err);
throw err;
}
};
export default myFetch;? 关键注意事项：
- 动态导入是必需的：await import(...) 在服务端执行时加载 next/headers，在客户端执行时加载 js-cookie，彻底规避模块环境不兼容问题；
- 不要省略 await：import() 返回 Promise，必须 await，否则 cookies() 调用会报错；
- js-cookie 需显式安装：npm install js-cookie，并确保未在服务端代码中静态引用它（避免打包污染）；
- Cookie 安全性建议：若 authToken 是 HttpOnly Cookie，请注意：客户端 JavaScript 无法读取 HttpOnly Cookie，此时应改用服务端 API 代理或 next/headers + Server Actions 统一鉴权；
-
TypeScript 类型增强：可为 myFetch 添加泛型
和更精确的 Response 处理逻辑，提升类型安全性与错误反馈能力； - 性能考量：动态导入会有微小延迟，但对首屏影响极低；如需极致性能，可考虑将 myFetch 拆分为 clientMyFetch 和 serverMyFetch 两个专用函数。
? 总结：Next.js 13 的服务端/客户端边界严格，跨环境访问 Cookie 必须遵循“环境感知 + 动态导入”原则。本文方案兼顾健壮性、可维护性与框架最佳实践，适用于绝大多数需要统一认证头的 Fetch 封装场景。
