很多 starter 只做到登录表单
登录页做出来了，但受保护路由、密码重置、邮箱验证和账户状态处理都还没真正完成。
Feature / Authentication
面向真实产品上线的认证能力，而不是只会展示登录页
BunShip 内置生产可用的认证层，覆盖邮箱流程、OAuth、受保护的 app 路由，以及独立的 admin 访问边界，适合真正上线 SaaS。
- 支持 Better Auth 或 Clerk
- 登录、注册、重置密码、验证邮件
- 营销站、App、Admin 的访问边界清晰
- 可直接与 billing、credits、admin 联动
2
认证路径
可按产品策略选择 Better Auth 或 Clerk。
< 1 天
接入改造
品牌替换、provider 配置与文案调整都比较直接。
4+
认证流程
登录、注册、密码重置、邮箱验证都已具备。
认证不是孤立的页面，而是已经接入 dashboard、账户状态与后台边界的产品流程。
受保护 dashboardSession 感知路由账户流程后台边界
这个页面要解决什么问题
认证模块的价值在于让买家快速判断：这不是半成品登录 UI，而是能接到真实产品链路上的 auth 基础设施。
过早被 provider 绑定
团队常常今天想用一种 auth，未来又想切换。BunShip 把这层边界做得更清楚。
后台权限与用户权限混在一起
运营后台的信任边界和普通用户完全不同，应该在产品结构里被明确分开。
What's included
页面要让买家和技术评估者一眼看懂认证能力具体包含哪些内容。
邮箱认证流程
登录、注册、重置密码、验证邮件都已经接入 App Router。
Provider 可替换路径
Better Auth 与 Clerk 都有明确叙事与文档支撑。
受保护路由模型
marketing、app、admin 在结构上已经体现访问边界。
Why it matters
认证不只是入口表单，而是整个产品信任链路的起点。
降低上线风险
买家可以看到账户、计费、后台入口都已经围绕身份系统连通。
提升 onboarding 速度
团队能把时间花在业务 onboarding，而不是重新拼 auth 基建。
支撑 AI 与 SaaS 付费流程
credits、subscriptions、generation history、admin 操作都依赖稳定身份体系。
Implementation notes
通过内链把评估型流量导向对应文档与转化页。
Who it's for
面向不同上线压力的人群，而不只是工程师。
独立开发者
跳过拼接登录、重置密码与权限路由的那一周。
创业团队
从一开始就拥有能与 billing、admin 协同工作的身份基础层。
Agency 团队
复用稳定 auth 基础设施，同时保留 provider 替换空间。
FAQ
先回答迁移与定制问题，减少转化阻力。
Next step
把认证当成可直接上线的产品基础，而不是旁支任务
继续看 pricing 完成商业评估，或者直接跳到 auth docs 看实施细节。