CI 徽章在每次推送时覆盖整个矩阵：在最旧和当前支持的 Go 上构建和测试、竞争检测器、代码审查、对面向攻击者的解析器进行模糊测试，以及针对真实 SQLite、PostgreSQL 和 MySQL 服务器的存储合规性套件。一个全面的、与框架无关的 Go 认证库，基于 better-auth 设计。支持电子邮件和密码、社交登录、会话、账户关联、双因素认证、凭证、魔法链接、组织、单点登录、管理工具、API 密钥和 JWT — 无外部依赖（纯标准库）。通过 go get github.com/go-dev-auth/go-dev-auth 进行安装。状态：预发布 1.0，已在生产环境使用，并向 v1.0 发展。该库在实际的 PostgreSQL 自动化项目中运行，使用完整的功能集。发布遵循 SemVer：虽然是预发布 1.0，公共 API 可能在次要版本之间发生变化（请锁定确切版本）；v1.0 冻结 API，从那时起，重大更改需升级主版本。其余的 v1.0 阈值包括可运行示例、新自动化 MySQL 功能的实际使用情况以及第三方安全审查。请查看存储适配器以确切了解在哪些后端得到了验证，并查看 docs/security-model.md 以了解威胁模型。功能包括核心电子邮件和密码认证（scrypt 哈希，兼容 better-auth 的哈希格式），通过 OAuth 2.0 / OIDC 使用 PKCE 的社交登录 — 内置 Google、GitHub、Discord、Facebook、Microsoft、Apple、GitLab、LinkedIn、Spotify、Twitch、X，以及适用于任何自定义提供商的声明性 oauth2.Spec。数据库支持的会话具有滑动过期、签名 Cookie、可选的 Cookie 缓存、列出/撤销端点。电子邮件验证、密码重置、修改电子邮件/密码、删除用户流程。账户关联与解除关联（可信提供商、令牌刷新、账户信息）。CSRF 来源检查、具有通配符子域的可信来源、基于 IP 的速率限制。存储适配器接口，内置数据库/sql（Postgres、MySQL、SQLite）和内存适配器，以及架构/迁移 SQL 生成。请求钩子、数据库钩子、自定义用户/会话字段。插件（镜像 better-auth 的插件系统）。相关功能包括：两因素认证 — TOTP、电子邮件 OTP 和备用代码；凭证 — WebAuthn 凭证，包含 CBOR/COSE 解析（无外部依赖）；魔法链接 — 无密码电子邮件链接；组织管理 — 组织、成员、角色、邀请、团队；单点登录 — 自带 OIDC 身份提供者，与电子邮件域匹配；管理员工具 — 用户管理、禁用、角色、模拟；API 密钥 — 带有作用域的哈希 API 密钥，像会话一样进行身份验证；JWT — EdDSA 签名的 JWT + JWKS 端点；承载 — 非浏览器客户端的授权头认证。快速入门包：主程序导入（"context" "net/http" "os" "time" godevauth "github.com/go-dev-auth/go-dev-auth" "github.com/go-dev-auth/go-dev-auth/storage/memory"）。主函数代码如下：func main() { auth, err := godevauth.New(godevauth.Config{BaseURL: "http://localhost:8080", // 必需 Secret: os.Getenv("AUTH_SECRET"), // 必需，32+ 随机字符 Database: memory.New(), // 必需 EmailAndPassword: godevauth.EmailPasswordConfig{Enabled: true}, // 生产环境必需 高级配置: godevauth.AdvancedConfig{TrustProxyHeaders: true, TrustedProxies: []string{"10.0.0.0/8"},},}) if err != nil { panic(err) } // 清理过期的一次性令牌和会话 defer auth.StartCleanup(context.Background(), time.Hour)() mux := http.NewServeMux() mux.Handle("/api/auth/", auth.Handler()) http.ListenAndServe(":8080", mux)} 处理程序是一个普通的 http.Handler，可以像 chi、echo、gorilla 或 gin（通过 gin.WrapH）一样挂载。如果你的前端运行在不同的源上，可以进行包裹：auth.CORS(auth.Handler()) 并将该源列入 TrustedOrigins。New 验证配置并返回错误，而不是以不安全的状态启动：缺少/短的 Secret、缺少或相对的 BaseURL（这决定了 Cookie 安全性、可信来源和重定向目标）、SameSite=none 而没有安全 Cookie，或 TrustProxyHeaders 没有 TrustedProxies 均会被拒绝。部署要求：告知其关于你的代理。速率限制和每个记录的会话 IP 依赖于解析客户端的地址。如果任何东西在此进程前终止连接 — AWS ALB、nginx、Cloudflare、Kubernetes ingress — 你必须说明，因为两个默认都是错误的：配置情况如下：如果没有设置，且在代理后运行。每个请求解析为代理的地址，因此所有客户共享一个桶。文档中严格规定的每 10 秒 3 次登录的规则变为整个系统每 10 秒 3 次，且限制器失败关闭。这是一种自取灭亡的故障。TrustProxyHeaders 没有 TrustedProxies，X-Forwarded-For 是客户提供的。任何调用者都会选择自己的桶，限制停止限制任何内容。TrustProxyHeaders + TrustedProxies 正确。转发头是 r