用途：在 Next.js 项目中集成 Clerk 认证，重点处理 App Router 下 @clerk/nextjs 的文件放置、受保护路由覆盖、服务端/客户端边界和现代中间件行为。
主要能力：用 ClerkProvider 包裹应用以提供认证上下文和预置组件；服务端用 @clerk/nextjs/server 的 auth() 读取会话状态、currentUser() 读取用户对象；用 clerkMiddleware() 配合 createRouteMatcher() 和 auth.protect() 保护路由；Pages Router 使用 getAuth(req)；服务端管理操作使用 clerkClient；客户端使用 useUser()、useAuth()、useClerk()。auth.protect() 可校验登录、角色、权限、功能与套餐，以及 session_token、oauth_token、api_key、m2m_token 等令牌类型。
使用方式：可参考 npx clerk@latest init --framework next 完成初始化，并核对生成文件是否符合当前 Next.js 版本与仓库规范。ClerkProvider 放在根布局。当前项目使用根目录或 src/proxy.ts，Next.js 15 及更早使用 middleware.ts，不要同时创建两者。注意 clerkMiddleware() 默认不保护任何路由，需显式添加保护逻辑，优先对高风险页面和变更型 API 采用正向匹配。Route Handler 与 Server Action 内部都要调用 auth() 或 auth.protect()。
适用场景：Next.js App Router 认证接入、受保护页面与 API、组织与权限控制、自定义域名与代理、CSP 配置、上线前排错。
限制与注意：auth() 仅服务端可用且依赖 clerkMiddleware()；CLERK_SECRET_KEY、CLERK_WEBHOOK_SIGNING_SECRET、CLERK_ENCRYPTION_KEY 不得进入客户端；生产与开发密钥不可混用；服务端 has() 对系统权限不可见，需按角色检查；未登录 API 可能返回 404 或 401，需按预期测试。具体价格与更多细节暂未提供。