登录注册全链路拆解：从表单校验到JWT安全加固

登录注册这功能，乍一看无非就是两个表单配两个接口，但真要在生产环境里把它做扎实，中间藏的细节能写满好几页。我做全栈开发这几年，见过太多项目在账号体系上翻车，有些是上线第一天就被脚本刷注册，有些是用户反馈“密码明明对了却登不进去”，还有些是改个密码把用户的所有会话踢掉引发投诉。这篇就把登陆注册的完整链路拆开揉碎，从前端表单一直讲到后端落库，再到会话保持和安全加固，把我踩过的坑、验证过的方案一起放出来，给需要从零搭建账号体系的同学做参考。

开始之前先说明一下，下面所有代码和流程用的是一套选型：前端以 Vue 3 + TypeScript 为例，后端用 Node.js + Express，数据库用 MySQL，会话方案选 JWT。选这套组合不是说别的技术栈不行，而是它足够通用，你换成 React 或 Spring Boot，核心逻辑照样套得上。

1. 动手之前先想清楚：用户表的字段设计与接口规划

很多新手上来就建一张表开写，结果做到一半发现缺字段，又要回头改表。登录注册虽然只是账号体系的入口，但它背后连着的用户表是整个系统的地基，字段设计从一开始就要想清楚。

用户表我最常用的一组字段是这样的：

CREATE TABLE `user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(32) NOT NULL, `email` varchar(128) DEFAULT NULL, `phone` varchar(20) DEFAULT NULL, `password_hash` varchar(255) NOT NULL, `nickname` varchar(32) DEFAULT NULL, `avatar_url` varchar(255) DEFAULT NULL, `status` tinyint NOT NULL DEFAULT 1, `token_version` int NOT NULL DEFAULT 0, `last_login_at` datetime DEFAULT NULL, `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`), UNIQUE KEY `uk_email` (`email`), UNIQUE KEY `uk_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

几个关键设计点解释一下：

• username 强制唯一，email 和 phone 允许为空但也要唯一。因为不是所有用户都会立刻绑定邮箱和手机，但一旦绑了就得唯一，否则后面做账号互通会出大麻烦。
• status 字段用来做账号启停。用户被封禁、注销或者邮箱未验证时都靠它区分，默认 1 表示正常。
• token_version 是给“踢用户下线”用的。用户修改密码或者后台强制退出时把这个字段加一，之前签发的 token 全部失效，这个字段的价值在后面安全章节会详细说。

接口层面，一个标准账号体系至少要有这么几个：

开发时给接口分好前缀，后面加权限中间件也方便。注册和登录属于公开接口，其余都要走鉴权。这里我习惯用/api/auth和/api/user分开，含义清晰，也方便做不同的限流策略。

1.1 JWT 的 Token 结构设计

Token 方案我选了 JWT，但 JWT 用不好会有很多坑。定义一个清晰的结构很重要：

Header: { "alg": "HS256", "typ": "JWT" } Payload: { "sub": "10001", "email": "user@example.com", "type": "access", "iat": 1699999999, "exp": 1700003599, "jti": "uuid-v4" }

一份 token 里至少要有用户 ID（sub）、token 类型（type）、签发时间（iat）、过期时间（exp）和唯一标识（jti）。type 字段区分 access_token 和 refresh_token，后面刷新和登出都要靠它。jti 配合 Redis 做黑名单，能实现真正意义上的服务端主动失效。

2. 注册链路：从表单校验到数据落库，每一层都不能省

注册这条链路是我见过踩坑最密集的地方。前端校验、后端校验、密码加密、防重复提交，每一层都有聊不完的细节。

2.1 前端表单的前置校验逻辑

前端注册表单的核心不是 UI 有多好看，而是校验逻辑要严密。我用 Vue 3 写过一个标准实现，核心校验规则是这样的：

interface RegisterForm { username: string; email: string; password: string; confirmPassword: string; } function validateForm(form: RegisterForm): Record<string, string> { const errors: Record<string, string> = {}; if (!form.username) { errors.username = "用户名不能为空"; } else if (form.username.length < 3 || form.username.length > 32) { errors.username = "用户名长度须为3到32个字符"; } else if (!/^[a-zA-Z0-9_\u4e00-\u9fa5]+$/.test(form.username)) { errors.username = "用户名只能包含字母、数字、下划线或中文"; } if (!form.email) { errors.email = "邮箱不能为空"; } else if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(form.email)) { errors.email = "邮箱格式不正确"; } const passwordErrors = validatePassword(form.password); if (passwordErrors.length > 0) { errors.password = passwordErrors.join("；"); } if (form.password !== form.confirmPassword) { errors.confirmPassword = "两次输入的密码不一致"; } return errors; } function validatePassword(password: string): string[] { const errors: string[] = []; if (password.length < 8) { errors.push("密码长度至少8位"); } if (!/[a-z]/.test(password)) { errors.push("密码必须包含小写字母"); } if (!/[A-Z]/.test(password)) { errors.push("密码必须包含大写字母"); } if (!/\d/.test(password)) { errors.push("密码必须包含数字"); } return errors; }

这套规则看起来简单，但每条背后都有实际事故支撑。用户名限定字符集是为了防脏数据和侵权账号；密码要求大小写+数字组合，是因为纯数字或纯字母密码在撞库攻击面前几乎没有抵抗力。校验逻辑要在一开始就定好，中途改会导致老用户没法登录。

2.2 密码强度策略应该怎么定：安全性与易用性的平衡

密码强度是个老生常谈但总是谈不透的话题。设得太简单，用户密码容易在撞库中泄露；设得太复杂，用户记不住就只能写在便利贴上，反而更不安全。

我的实践经验是分档处理：

• 最低要求：至少 8 位，必须包含字母和数字
• 推荐要求：至少 10 位，大小写字母+数字+特殊字符任选其三
• 高强度要求：至少 12 位，四类字符都包含

注册时按推荐要求校验，登录时不限制密码长度。因为密码哈希只在注册和修改时生成，登录只需要比对结果。限制登录时的密码长度反而会泄露“密码策略”的信息，给攻击者缩小猜测范围。

2.3 前后端表单都校验，为什么不能只依赖前端

前端校验纯属为了用户体验，让用户不用等网络往返就能立刻看到错误提示。真正把安全隐患挡在门外的，是后端校验。

后端校验要做的比前端更多：

1. 校验 username 格式和长度 2. 校验 email 格式 3. 校验 password 强度 4. 检查 username 是否已存在 5. 检查 email 是否已被注册 6. 校验验证码（如果有） 7. 检查该 IP 的注册频率是否超限

后端校验代码我习惯写成独立模块，跟前端校验规则保持同步，但数据源完全不同。前端的规则藏在 JavaScript 代码里可以被篡改，后端规则才是一道真正能把脏数据挡在数据库之外的门禁。

一个典型的后端注册接口实现大概是这样的：

const bcrypt = require('bcrypt'); const { pool } = require('../db'); const { validateRegisterInput } = require('../validators'); async function register(req, res) { const { username, email, password } = req.body; const errors = validateRegisterInput({ username, email, password }); if (errors.length > 0) { return res.status(400).json({ code: 400, message: errors[0] }); } const existUser = await pool.query( 'SELECT id FROM user WHERE username = ? OR email = ?', [username, email] ); if (existUser.length > 0) { return res.status(409).json({ code: 409, message: '用户名或邮箱已被注册' }); } const saltRounds = 12; const passwordHash = await bcrypt.hash(password, saltRounds); const result = await pool.query( `INSERT INTO user (username, email, password_hash, nickname) VALUES (?, ?, ?, ?)`, [username, email, passwordHash, username] ); const userId = result.insertId; const { accessToken, refreshToken } = generateTokenPair(userId, username); res.status(201).json({ code: 0, data: { userId, accessToken, refreshToken } }); }

2.4 密码加密的规矩：只存 Hash，永远不存明文

密码不能明文存数据库，这是底线，但我见过不少小项目在早期偷懒，把密码直接放数据库里。等后来被脱库才追悔莫及。

正确做法是用 bcrypt 这样的自适应哈希算法。它自带盐值，每次哈希结果都不同，而且可通过提高成本因子让暴力破解的效率指数级下降。

实际项目里我通常选的 saltRounds 是 12，单次 hash 耗时大约 200-300ms。这个时间对正常用户来说几乎无感，但攻击者想暴力破解每个密码的成本就上去了。如果服务器性能一般，降到 10 也行，但千万别低于 10。

有一点必须注意：bcrypt 输入有 72 字节的长度限制，超过部分会被静默截断。这是很多人踩过的大坑——用户注册时输了个很长的密码，登录时输同样长也能过；但如果有两个密码前 72 字节相同，后面不同，bcrypt 居然会认为它们是同一个密码。所以要么前端限制最大长度，要么在哈希前对长密码做一次预先处理。

2.5 邮箱/手机验证码的激活逻辑

注册后是否要验证邮箱或手机，取决于业务需要。做社区或电商类产品建议必须验证，否则垃圾账号会污染整个用户体系。

完整流程是这样的：

1. 用户提交注册信息，创建 status=0 的未激活账号 2. 系统生成 6 位数字验证码，存入缓存 3. 发送验证码到用户邮箱/手机 4. 用户填写验证码，调用激活接口 5. 后端比对验证码是否正确且未过期 6. 激活成功后将 status 置为 1

注册后要不要自动登录也值得商榷。我倾向于先自动登录，但界面上引导用户去验证邮箱。如果强制没验证就不让登录，很多用户会在注册当天流失。

验证码有两个要点：有效期建议 10 分钟，验证错误次数不能超过 5 次。太久容易出安全漏洞，太短用户来不及填。超过次数限制就作废，要求重新获取。

3. 登录链路：凭证校验、会话建立与状态恢复

注册入口没问题之后，登录就是整个系统里调用频率最高的接口了。登录做得好不好，直接决定用户每天打开应用的第一感受。

3.1 支持用户名/邮箱/手机号三种方式登录

很多人觉得登录表单简单，一个输入框一个密码框就完了。但三种登录方式（用户名、邮箱、手机号）和密码之间怎么组合校验，里面的门道不少。

我的做法是前端不明确告诉用户用哪种方式登录，一个输入框直接收，后端自动识别：

function identifyLoginAccount(account) { if (/^1[3-9]\d{9}$/.test(account)) { return { type: 'phone', value: account }; } if (/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(account)) { return { type: 'email', value: account.toLowerCase() }; } return { type: 'username', value: account }; }

后台根据识别结果去对应的唯一索引查用户。用邮箱登录时需要统一转小写再查，避免用户有时候输大写有时候输小写导致查不到。用手机号登录时只认数字，去掉空格和横线。

3.2 密码校验接口的响应细节：统一错误提示

登录接口的错误提示要格外谨慎。很多小项目会在用户名不存在时提示“该用户名未注册”，密码错误时提示“密码错误”。这等于给黑客提供了一张“哪个用户存在”的地图。

统一策略是：无论用户名不存在还是密码错误，都返回同一个错误信息：“用户名或密码错误”。同时接口延迟也尽量统一，把密码校验失败和用户不存在的响应时间差抹平，防止时序攻击。

简单说就是让攻击者在不同的错误情况下观察到相同的响应时间和错误信息，他们就无法确认一个账号是否真实存在。

响应体统一走这个结构：

{ "code": 0, "message": "success", "data": { "accessToken": "...", "refreshToken": "...", "userInfo": { "id": 10001, "username": "zhangsan", "nickname": "张三" } } }

3.3 双 Token 机制：为什么不用单 Token

早期的 Web 应用很多是单 Token 方案：登录发一个 token，过期了就让用户重新登录。简单的内部项目没问题，但面向 C 端用户的产品绝不能这么干。7 天过期太短，用户嫌烦；30 天过期太长，token 泄露的风险窗口太大。

双 Token 机制是行业普遍采用的折中方案：

access_token 短命，即使被截获也只有十几分钟的有效期。refresh_token 生命周期长，但只干一件事——换新的 access_token，而且刷新时可以带上设备信息做校验。

这个方案的核心价值在于：让短期凭证尽量短，长期凭证尽量少在网络上传输。短 token 频繁更换，泄露影响小；长 token 只在刷新时用一次，泄露概率大大降低。

3.4 生成 Token 的完整实现

Token 生成和刷新建议封装成一个模块，所有地方统一调用：

const jwt = require('jsonwebtoken'); const crypto = require('crypto'); function generateTokenPair(userId, username) { const accessToken = jwt.sign( { sub: userId, username, type: 'access', jti: crypto.randomUUID() }, process.env.ACCESS_TOKEN_SECRET, { expiresIn: '15m' } ); const refreshToken = jwt.sign( { sub: userId, type: 'refresh', jti: crypto.randomUUID() }, process.env.REFRESH_TOKEN_SECRET, { expiresIn: '7d' } ); return { accessToken, refreshToken }; } async function refreshAccessToken(refreshToken) { try { const decoded = jwt.verify(refreshToken, process.env.REFRESH_TOKEN_SECRET); if (decoded.type !== 'refresh') { throw new Error('Invalid token type'); } const user = await getUserById(decoded.sub); if (!user || user.status !== 1) { throw new Error('User not found or disabled'); } const newAccessToken = jwt.sign( { sub: user.id, username: user.username, type: 'access', jti: crypto.randomUUID() }, process.env.ACCESS_TOKEN_SECRET, { expiresIn: '15m' } ); return newAccessToken; } catch (err) { throw new Error('Invalid refresh token'); } }

两个 secret 分开配，并且要求环境变量里设置，不要写死在代码里。refresh 接口拿到旧 refresh_token 后还可以选择轮换——签一个新 refresh_token 并撤销旧的，进一步降低长期凭证被重放的风险。

3.5 登录成功后的用户状态恢复

用户登录完成后，前端的核心任务是把用户信息放进全局状态里，让整个应用立刻知道“现在是谁在操作”。

我用 Pinia 管理用户状态，登录后的处理逻辑大概是：

// stores/auth.ts export const useAuthStore = defineStore('auth', { state: () => ({ accessToken: localStorage.getItem('accessToken') || '', refreshToken: localStorage.getItem('refreshToken') || '', userInfo: null as UserInfo | null }), actions: { async login(account: string, password: string) { const { data } = await api.post('/auth/login', { account, password }); this.accessToken = data.accessToken; this.refreshToken = data.refreshToken; this.userInfo = data.userInfo; localStorage.setItem('accessToken', data.accessToken); localStorage.setItem('refreshToken', data.refreshToken); }, async fetchMe() { const { data } = await api.get('/auth/me'); this.userInfo = data; }, logout() { this.accessToken = ''; this.refreshToken = ''; this.userInfo = null; localStorage.removeItem('accessToken'); localStorage.removeItem('refreshToken'); } } });

路由守卫里监听用户状态，未登录访问受保护页面时自动跳转到登录页。之前访问的目标页面要记在路由的 query 参数里，登录成功后把它取出来跳转回去。这个回跳逻辑看着不起眼，但用户从分享链接点进来被强制登录的感受，就靠它挽回。

4. 安全加固：防止爆破、密码保护与常见攻击面梳理

登录注册接口是系统最容易被攻击的入口，几乎每天都会收到来自脚本的扫描和爆破请求。这一章把我在生产环境遇到的主要攻击手法和对应防御方案梳理一遍。

4.1 登录接口的速率限制与防爆破策略

暴力破解的核心是“不断尝试”，防御思路就是让尝试变得极慢或直接停下来。

我最常用的三层限流：

第 1 层：单 IP 限流 - 同一 IP 每分钟最多 10 次登录尝试 第 2 层：单用户限流 - 同一账号每分钟最多 5 次密码尝试 第 3 层：延迟惩罚 - 连续失败后，每次响应延迟递增

实现时可以用 Redis 计数器：

const redis = require('redis'); const client = redis.createClient(); async function checkLoginRateLimit(ip, account) { const ipKey = `login:ip:${ip}`; const accountKey = `login:account:${account}`; const [ipCount, accountCount] = await Promise.all([ client.incr(ipKey), client.incr(accountKey) ]); if (ipCount === 1) await client.expire(ipKey, 60); if (accountCount === 1) await client.expire(accountKey, 60); if (ipCount > 10 || accountCount > 5) { return { allowed: false, retryAfter: 60 }; } return { allowed: true }; }

账户锁定策略要不要做，得看业务形态。对 C 端产品建议只做“临时锁定”，比如连续失败 10 次后锁定 15 分钟，而不是永久锁定。永久锁定会被攻击者利用来对目标用户搞拒绝服务——我只要用你的账号名不断输错密码，你就永远登不上去。

4.2 密码存储的最优实践与 bcrypt 参数调优

bcrypt 的成本因子直接决定安全性和性能的平衡点。我的经验值设定依据是这样的：

cost=10: 约 100ms/次，适合高并发、低安全要求 cost=12: 约 250ms/次，适合大部分业务系统 cost=14: 约 1000ms/次，适合金融、高安全场景

选 12 是因为 250ms 在用户体验上几乎感知不到，但对攻击者来说，同一台机器单线程每秒只能尝试 4 次。配合限流，爆破整个密码空间的时间是以年计算的。

还有一个容易被忽略的细节：升级用户的密码哈希。如果系统早期用了 MD5 或 SHA1，可以在用户登录成功后自动检测哈希前缀，发现是老算法就用 bcrypt 重新哈希并更新到数据库，让所有存量账号平滑迁移到新算法。

4.3 前端存储 Token 的方式对比：localStorage 与 HttpOnly Cookie

这是一个经常引起争论的话题。我用一张表把两种方案的区别摆出来：

针对 C 端产品，我更推荐 access_token 放内存或 localStorage，refresh_token 放 HttpOnly Cookie。两个 token 分开放的好处是：短暂泄露 access_token 影响面可控（15 分钟就失效），refresh_token 在 HttpOnly Cookie 里，即使页面被注入脚本也没法直接读走。

4.4 CSRF 与 XSS 的防护细节

如果选型里有 HttpOnly Cookie，就一定逃不开 CSRF 问题。我系统地梳理一下两层防线。

XSS 防护的核心是输出编码和输入过滤：

• 所有用户输入进数据库前，去除危险标签和脚本
• 所有从数据库输出的内容，在渲染前做 HTML 转义
• 前端开启 CSP（Content Security Policy），关掉内联脚本执行权限
• 页面只用 HTTPS，防止中间人篡改内容

CSRF 防护的核心是验证请求来源和带校验令牌：

// 后端中间件示例：校验 CSRF Token async function csrfProtection(req, res, next) { // 从请求头或请求体取 csrf token const csrfToken = req.headers['x-csrf-token']; if (!csrfToken) { return res.status(403).json({ code: 403, message: 'CSRF token is required' }); } // 与 HttpOnly Cookie 里存的 session 中的 token 比对 const sessionToken = req.session.csrfToken; if (!sessionToken || sessionToken !== csrfToken) { return res.status(403).json({ code: 403, message: 'Invalid CSRF token' }); } next(); }

再配合 SameSite=Lax 或 Strict 的 Cookie 属性，双管齐下之后 CSRF 攻击基本可以杜绝。

4.5 修改密码后的会话失效策略

用户修改密码之后，所有已登录的设备都应该强制下线。JWT 天生是无状态的，要废掉已签发的 token 最优雅的方式就是用前面提到的 token_version 字段。

async function changePassword(userId, oldPassword, newPassword) { const user = await getUserById(userId); const isMatch = await bcrypt.compare(oldPassword, user.password_hash); if (!isMatch) { throw new Error('原密码错误'); } const newHash = await bcrypt.hash(newPassword, 12); await pool.query( 'UPDATE user SET password_hash = ?, token_version = token_version + 1 WHERE id = ?', [newHash, userId] ); }

JWT 校验中间件里把 token_version 一起比对，要求 token 里的版本号和数据库里的当前版本一致才放行。修改密码后版本号加一，所有旧 token 立刻失效，包括攻击者已经偷走的那些。

5. 边界情况与体验细节：容易被忽略但直接影响口碑的点

功能和安全性都到位之后，真正让用户觉得“这产品靠谱”的，往往是那些不会被写进需求文档里的边角细节。这一章专门聊那些容易被忽略但直接影响用户体验的坑。

5.1 用户已注册/邮箱已存在时的提示策略

注册时用户名或邮箱重复该怎么提示？简单粗暴地提示“用户名已存在”会造成隐私问题。攻击者可以遍历注册接口，摸清哪些邮箱已经注册过。

我的策略是这样：

• 用户名重复：直接提示“用户名已被占用”，因为用户名本身就是半公开信息
• 邮箱重复：提示“邮箱已被注册”，但同时在邮件里告诉用户“如果你不记得注册过，可以走找回密码流程”
• 手机号重复：类似邮箱，提示后引导用户走“手机号已注册，去登录/找回密码”

敏感账号的“是否注册过”这个信息，尽量别通过接口暴露得太干脆。用邮件或短信的措辞去引导，比页面直接告诉访问者“这个邮箱是某某某的”要稳妥得多。

5.2 登录状态下的注册页与登录页处理

一个真实场景：用户已经登录了，又手动去访问/login或/register。这个时候应该直接跳转到首页或用户中心，而不是傻傻地展示一个登录表单让他再登一次。

路由守卫里的处理逻辑：

router.beforeEach((to, from, next) => { const authStore = useAuthStore(); const isLoggedIn = !!authStore.accessToken; if (isLoggedIn && (to.path === '/login' || to.path === '/register')) { next('/'); return; } if (!isLoggedIn && to.meta.requiresAuth) { next({ path: '/login', query: { redirect: to.fullPath } }); return; } next(); });

这个细节不算技术难点，但几乎每个产品上线后都会遇到用户提问“我明明登录了，为什么还能打开登录页”。

5.3 前端加载态与按钮防重复提交

注册和登录接口都有网络延迟，用户点击按钮后如果没有任何反馈，第一反应就是再点一次。重复提交的后果在小并发时也许只是多写一条脏数据，在高并发时就是重复注册、重复扣费这类严重事故。

前端处理有三个要点：

1. 点击后立即进入 loading 态，按钮禁用并显示“登录中”/“注册中”
2. 接口响应前不允许再次提交
3. 请求失败后按钮恢复，但保留用户已填写的表单内容

<template> <button :disabled="loading" @click="handleSubmit"> {{ loading ? '登录中...' : '登录' }} </button> </template> <script setup lang="ts"> const loading = ref(false); async function handleSubmit() { if (loading.value) return; loading.value = true; try { await authStore.login(formData); // 跳转逻辑 } finally { loading.value = false; } } </script>

后端同样要防重复提交。注册接口可以在 Redis 里放一个以邮箱为 key 的短时锁，比如 3 秒内不允许同一邮箱重复提交：

const lockKey = `register:lock:${email}`; const locked = await client.set(lockKey, '1', { NX: true, EX: 3 }); if (!locked) { return res.status(429).json({ code: 429, message: '操作太频繁，请稍后再试' }); }

5.4 前后端时间不一致导致的 Token 过期问题

JWT 的 exp 用的是 Unix 时间戳（秒），这是绝对时间。如果服务器时间和客户端时间偏差过大，就会出现“客户端显示正常，但接口一直报 token 过期”的诡异问题。

这个问题有两个解决方向：

1. 客户端时钟同步：应用启动时从服务端获取标准时间，计算本地偏差
2. 服务端宽松策略：校验 exp 时允许 30 秒的时钟偏移量

时钟偏移量该设多少？我建议 30 秒。 太小，用户设备时间偏差稍大就误报； 太大，token 的有效期又多出了不必要的安全窗口。

5.5 中文用户名、Unicode 特殊字符与大小写的坑

Unicode 和字符规范化问题在中文互联网产品里非常常见，尤其是涉及用户名、邮箱这类唯一约束字段时。

最典型的坑是邮箱大小写。ZhangSan@Example.com和zhangsan@example.com在规范里被认为是同一个邮箱，但如果你直接用字符串精确匹配，就会在数据库里存两条记录，用户后面就分不清哪个是哪个了。

统一处理方案：

• 邮箱：存储和查询前统一.toLowerCase()
• 用户名：如果允许中文，用utf8mb4字符集存储，保留原始大小写，但唯一性约束用大小写不敏感排序规则
• 手机号：只存数字，去掉空格、横线、国家区号前导零

数据库层面，如果用户名要求大小写不敏感的唯一性，MySQL 里可以把字段排序规则设为utf8mb4_general_ci或utf8mb4_0900_ai_ci，这样ZhangSan和zhangsan在唯一索引层面会被识别为重复，但存储时仍然保留用户输入的原始格式。

5.6 登录后回跳原页面与多标签页同步

用户在未登录状态下访问受保护页面，被重定向到登录页，登录成功后应该跳回之前的页面。这个方案在路由守卫里已经写了，但要注意从 query 参数取回来的 redirect 地址必须做白名单校验，防止恶意链接拼接，比如用户在 A 站点了带redirect=https://evil.com的链接，登录后却被带到了钓鱼网站。

多标签页同步是另一个容易被忽略的细节。用户在一个标签页登录了，另一个标签页还停留在登录页。用storage事件监听 localStorage 的变化，登录或登出状态在主标签页变化时，同步通知所有标签页更新状态：

window.addEventListener('storage', (event) => { if (event.key === 'accessToken') { if (event.newValue) { // 其他标签页：同步登录状态 authStore.fetchMe(); } else { // 其他标签页：同步登出状态 authStore.resetState(); } } });

这个功能不是必需的，但做了之后用户体验会明显上一个档次，尤其是那些习惯一次开好几个后台页面的用户。

我在几个项目里实际落过这套方案，对比下来最直观的感受是：登录注册模块写得稳，整个系统的其他模块做起来才踏实。用户体系是所有业务的地基，地基里的一块砖铺歪了，后面盖多少层楼都得回来返工。尤其是 Token 方案和安全策略这两块，一定要在项目早期就定好方向，因为上了线之后再改，牵涉的是所有存量用户的登录状态，改动成本和风险完全不在一个量级上。