企业官网建设流程全解析

注册接口大概是后端系统开发里最容易被低估的一个接口。刚接手需求的人通常觉得，不就是收两个参数、往表里插一行数据，半小时的事；真把它放到线上跑几个月，你会发现这个接口出的问题比任何一个业务查询接口都多——重复注册、并发穿透、脏数据、被脚本批量刷请求，这些坑基本都藏在注册这条链路上。我前后经手过几个不同规模的系统，用户量从几千到上百万的都有，注册接口的代码改过至少五六个版本，每次重构都能发现上一版没考虑到的地方。这篇就把创建注册接口这件事从头到尾拆一遍：怎么定接口契约、密码该怎么存、唯一性怎么保证、并发怎么写才不出脏数据、上线前该测什么，适合刚接触后端系统开发的朋友照着落地，也适合有经验的人拿去对照自己的实现查漏补缺。

1. 注册接口的整体设计与技术选型考量

1.1 为什么注册接口值得单独拿出来设计

很多人写注册接口的习惯是先在控制器里堆代码：取参数、查数据库、判断重复、插入、返回。功能能跑通，但如果这套逻辑被复制到"手机号注册""邮箱注册""第三方账号绑定"几个入口，代码会迅速膨胀成一坨。我在一个老系统里见过同一段查重逻辑被复制了四份，其中三份写法还不一样，最后修一个边界条件要改四个地方，改漏一个就出线上问题。

所以我现在的做法是先把注册这条链路的职责拆清楚：控制器只负责协议层面的东西（解析请求、调用服务、把结果转成统一响应），服务层负责业务规则（校验、查重、哈希、事务），仓储层负责数据读写。这样做的直接好处是，注册规则变化时只动服务层，换数据库或加缓存只动仓储层，测试也能分层写——服务层用内存数据库跑单元测试，控制器层只测协议转换。

另一个常被忽略的点是注册接口的"外溢影响"。它不只是一个写接口，还是整个账号体系的入口。后面所有的登录、找回密码、账号注销、风控封禁，都依赖注册时落下的数据是否干净。注册时用户名没做大小写归一化，登录时就会出现"明明注册过却登不上"的客诉；注册时没记录来源渠道，后面做增长分析就得从日志里刨。这些都是在设计阶段花十分钟想清楚、能省后面几个月麻烦的事。

1.2 先定契约：请求与响应字段的设计

我习惯在写代码之前先把接口契约用表格列出来，跟调用方对齐。注册接口的契约没定好，后面改字段的沟通成本远大于开发成本。

请求字段我一般这么设计：

响应体统一成三段式结构，业务码、提示语、数据。业务码不要直接复用 HTTP 状态码做业务判断，两者职责不同：HTTP 状态码表达传输层结果，业务码表达业务语义。我见过用 200 表示成功、400 表示用户名重复、401 表示密码太弱的写法，后来接入网关做统一鉴权时直接撞车，改起来牵一发动全身。

{ "code": 0, "message": "success", "data": { "user_id": 1000231, "username": "demo_user" } }

关于错误提示的粒度，这里有个体验和安全的权衡。注册接口如果对"用户名不存在"和"用户名已存在"给出不同提示，本质上就是在帮攻击者做账号枚举。但注册场景下你不提示"已存在"，用户根本没法完成操作。我的处理是：注册接口允许明确提示重复，但同时上频率限制和验证码，把枚举成本抬到足够高；而登录、找回密码这类接口一律给模糊提示。这是行业里比较通行的折中，不是最优解，但工程上可接受。

1.3 技术栈与分层结构的取舍

示例代码我用 Python 的 FastAPI 配 SQLAlchemy，数据库选 PostgreSQL。选它的理由很实际：Pydantic 做入参校验几乎是零成本，SQLAlchemy 的事务和异常体系比较完整，PostgreSQL 的部分唯一索引能优雅处理软删除和唯一约束的冲突。你要是用 Java 那套 Spring Boot 加 MyBatis，思路完全一样，只是校验注解换成 Bean Validation，异常处理换成全局异常处理器。

数据库这块我建议尽量别在注册接口里引入太多外部依赖。有些方案会在注册时同步写 Redis、发消息队列、调用户中心，链路一长，失败点就多。注册是个强一致场景，用户点了提交就得知道结果，异步化在这里收益很低。我的原则是：注册主链路只碰主库，通知类动作（发欢迎邮件、发优惠券）放到事务提交后异步做，失败也不影响注册结果。

注意：注册接口不要放在只读从库上，也不要为了"减轻主库压力"把查重查询打到从库。主从延迟在几百毫秒级别，高并发下会出现"查不到重复但插入撞唯一索引"的情况，虽然有兜底，但错误率会明显上升。

2. 核心细节解析：从参数进来到数据落库的每一道关卡

2.1 入参校验的三层过滤

校验这事情，我的经验是分三层做，每层职责不同，不要混着写。

第一层是框架层，用 Pydantic 或 Bean Validation 把类型、长度、格式这些机械规则声明式地写掉。这层的好处是错误信息标准化，不用手写一堆 if。字段定义里把 min_length、max_length、正则都写上，非法请求在进入业务逻辑之前就被拦掉，省去后面到处判空。

第二层是业务规则层，处理那些框架表达不了的约束。比如"用户名不能是保留字"（admin、root、system 这类），"密码不能包含用户名"，"邀请码必须存在且未过期"。这些规则依赖业务数据，只能放在服务层。

第三层是数据层，靠数据库的约束做最终兜底。NOT NULL、唯一索引、CHECK 约束。这层看起来最笨，但它是唯一能防住并发和绕过路径的。我在一次故障里深刻体会到这点：某次上线新入口时忘了走服务层校验，直接调了仓储层的插入方法，结果写进去一批用户名为空的脏数据，最后还是靠表上的 NOT NULL 约束才没让问题扩散得更大。

三层里最容易被偷懒省掉的是第三层。有人觉得服务层都校验过了，数据库约束是冗余。冗余确实存在，但成本极低，收益是防住所有非预期写入路径，这笔账怎么算都划算。

2.2 密码存储：算法、盐与成本参数

密码这块不能有任何发挥空间，规则就一条：只存哈希，用专门为密码设计的慢哈希算法。

先说什么不能用。MD5、SHA-1、SHA-256 这些通用摘要算法一律不行，原因是它们太快了。一张消费级显卡每秒能算几十亿次 SHA-256，泄露的哈希表拿字典跑一遍，弱密码几分钟就出来了。而且这些算法不带盐，相同密码的哈希值一样，撞库时能批量匹配。我见过一个老系统用 MD5 存密码，后来做安全审计，把常见弱口令跑了一遍，直接还原出三千多个明文账号。

现在的主流选择是 bcrypt 和 argon2。bcrypt 胜在成熟、各语言都有稳定实现，成本参数（cost）控制迭代轮数，每加 1 计算量翻倍。我的经验值是 cost 取 10 到 12：取 10 时单次哈希大概几十毫秒，登录接口在正常 QPS 下完全扛得住；再往上加，CPU 开销增长很快，注册和登录都会变慢，影响用户体验。argon2id 是更新的选择，内存和 CPU 双重成本，抗 GPU 破解更强，如果框架支持我优先用它。

关于盐，bcrypt 和 argon2 都是自动生成随机盐并把它编码进哈希串里的，不需要你手动维护盐字段。这点经常有人搞错，以为要自己生成盐存一列。实际存储时只需要一个 varchar(255) 的字段，把完整哈希串存进去，校验时用算法库自带的 verify 方法，它会自己从哈希串里解析出盐和参数。

import bcrypt def hash_password(plain: str) -> str: # bcrypt 自动生成盐，结果串里已包含算法标识、cost、盐和摘要 return bcrypt.hashpw(plain.encode("utf-8"), bcrypt.gensalt(rounds=12)).decode("utf-8") def verify_password(plain: str, hashed: str) -> bool: return bcrypt.checkpw(plain.encode("utf-8"), hashed.encode("utf-8"))

还有一个细节：密码长度上限要设。bcrypt 只处理前 72 字节，超长部分会被截断，这就导致两个前 72 字节相同的密码被视为同一个。要么把上限设成 64 字符并在校验层拦住，要么换 argon2（没有这个限制）。我现在的做法是统一限制 8 到 64 字符，同时在文档里写清楚。

注意：不要把密码明文、明文密码的哈希、验证码写进日志。排查问题时习惯性打一行log.info(request.body)，这行代码可能让整个团队上安全事故通报。日志里涉及密码字段一律过滤成固定占位符。

2.3 唯一性保障：预检查与数据库唯一索引的双保险

"注册前先查一下用户名有没有被占用"这个逻辑，单独用是不安全的。两个请求同时进来，都查了一次，都发现没占用，然后都插入——如果表上没有唯一索引，两条重复数据就进去了。这个窗口很窄，但在秒杀或营销活动期间，正好会有大量并发注册，撞上的概率一点不低。

正确做法是两道防线一起用：

第一道是预检查，目的是给用户友好的提示，避免每次都靠数据库报错来反馈。查询时走唯一索引，速度快，命中率高。

第二道是数据库唯一索引，作为最终保证。插入时如果违反唯一约束，捕获对应的异常，转成同样的业务错误返回给用户。两道防线得到的提示信息应该完全一致，用户不需要知道他是被哪一道拦下的。

from sqlalchemy.exc import IntegrityError from app.errors import BizError def create_user(db, username: str, email: str, raw_password: str): username_lower = username.strip().lower() exists = db.query(User.id).filter(User.username_lower == username_lower).first() if exists: raise BizError(40901, "用户名已被占用") user = User( username=username.strip(), username_lower=username_lower, email=email.strip().lower(), password_hash=hash_password(raw_password), ) db.add(user) try: db.commit() except IntegrityError: db.rollback() raise BizError(40901, "用户名已被占用") return user

这段代码里有个容易被忽略的点：捕获 IntegrityError 后必须显式 rollback。SQLAlchemy 在事务失败之后会话处于不可用状态，不 rollback 直接继续用会抛一堆莫名其妙的异常。我早期就被这个坑过，报错信息指向下一行代码，查了半天才定位到是事务没回滚。

另外注意username_lower这个冗余字段。数据库里做大小写不敏感的唯一约束有几种方式，用 citext 扩展、用函数索引、或者存一个归一化字段。我倾向最后一种，因为它的行为最直观，跨数据库迁移也最省事。代价是多一列、多一次写入，几乎可以忽略。

2.4 事务边界：一次注册到底该写几张表

简单系统里注册只写一张用户表，复杂一点会涉及用户表、用户资料表、积分账户表。这几张表必须在同一个事务里写，否则用户主表插进去了、资料表失败，就会产生一条"残缺"的账号，后续登录走资料查询直接空指针。

我一般把事务边界放在服务层方法上，用装饰器或者上下文管理器包住整个注册流程。需要注意的是，事务里不要做耗时操作——不要在里面调外部接口、发短信、生成头像。这些动作放在提交之后，用事件或者后台任务异步处理。

def register(db, payload): with db.begin(): # 事务开始 user = create_user(db, ...) # 写主表 create_profile(db, user.id) # 写资料表 create_point_account(db, user.id) # 写积分账户 # 事务提交后再做通知 notify_welcome(user) return user

还有个细节是异常处理的位置。业务异常（用户名重复、验证码错误）应该正常回滚并返回明确提示；系统异常（数据库连接断开、磁盘满）要回滚并返回通用错误，原始异常记日志但不要透给前端。两者的区别在于用户是否需要根据提示调整操作，代码里要分开 catch。

3. 实操过程：把注册接口从头跑通

3.1 表结构设计与索引规划

先把表建起来。下面的建表语句是 PostgreSQL 语法，MySQL 的话把 BIGSERIAL 换成 BIGINT AUTO_INCREMENT，TIMESTAMPTZ 换成 DATETIME，其余基本一致。

CREATE TABLE app_user ( id BIGSERIAL PRIMARY KEY, username VARCHAR(32) NOT NULL, username_lower VARCHAR(32) NOT NULL, email VARCHAR(128) NOT NULL, email_lower VARCHAR(128) NOT NULL, password_hash VARCHAR(255) NOT NULL, status SMALLINT NOT NULL DEFAULT 1, register_ip VARCHAR(45), invite_code VARCHAR(32), created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); CREATE UNIQUE INDEX uk_user_username_lower ON app_user (username_lower) WHERE status <> 0; CREATE UNIQUE INDEX uk_user_email_lower ON app_user (email_lower) WHERE status <> 0;

这里用了部分唯一索引，带上WHERE status <> 0条件。原因是：账号注销后 status 置 0，用户名理论上可以释放出来给别人用，但历史上注销的账号还得留档。如果直接建全表唯一索引，注销账号的用户名就永远被占着，客服会天天被问"我这个名字明明没人用为什么注册不了"。带条件的索引让注销记录不参与唯一性判断，同时又保留历史数据。

这个设计有个隐患要知道：一旦注销账号的名字被新用户用了，将来老用户想找回账号就冲突了。所以业务上要么明确告知"注销后用户名不可找回"，要么给注销账号留一个冻结期（比如 90 天）再释放。这个决策不是技术能定的，得和产品对齐，但技术上必须留出这个口子。

索引规划上，注册接口涉及的查询就两类：按 username_lower 查、按 email_lower 查，两个唯一索引正好覆盖，不需要额外建索引。别在这个表上乱建索引，注册是写操作，索引越多插入越慢。

3.2 完整接口代码实现

下面是最小可用版本，包含契约定义、校验、服务调用和异常处理。

import re from fastapi import APIRouter, Depends, HTTPException from pydantic import BaseModel, EmailStr, field_validator from sqlalchemy.orm import Session router = APIRouter(prefix="/api/v1") USERNAME_PATTERN = re.compile(r"^[A-Za-z][A-Za-z0-9_]{3,31}$") RESERVED_NAMES = {"admin", "root", "system", "support", "official"} class RegisterRequest(BaseModel): username: str email: EmailStr password: str @field_validator("username") @classmethod def check_username(cls, v: str) -> str: v = v.strip() if not USERNAME_PATTERN.match(v): raise ValueError("用户名需以字母开头，4-32 位字母数字下划线") if v.lower() in RESERVED_NAMES: raise ValueError("该用户名不可用") return v @field_validator("password") @classmethod def check_password(cls, v: str) -> str: if not 8 <= len(v) <= 64: raise ValueError("密码长度需在 8-64 位之间") if not re.search(r"[A-Za-z]", v) or not re.search(r"\d", v): raise ValueError("密码需同时包含字母和数字") return v @router.post("/register") def register(payload: RegisterRequest, db: Session = Depends(get_db)): user = register_service(db, payload) return {"code": 0, "message": "success", "data": {"user_id": user.id, "username": user.username}}

服务层的细节：注册前先查重，查重用first()加上limit 1的语义，别用count()，count 会扫全部匹配行，纯属浪费。哈希计算放到查重之后做，避免为重复用户名白白消耗一次 bcrypt 计算——bcrypt 一次几十毫秒，被恶意请求刷的时候这个开销很可观。

def register_service(db: Session, payload: RegisterRequest): username_lower = payload.username.lower() email_lower = payload.email.lower() if db.query(User.id).filter(User.username_lower == username_lower).first(): raise BizError(40901, "用户名已被占用") if db.query(User.id).filter(User.email_lower == email_lower).first(): raise BizError(40902, "该邮箱已注册") pwd_hash = hash_password(payload.password) with db.begin(): user = User(username=payload.username, username_lower=username_lower, email=payload.email, email_lower=email_lower, password_hash=pwd_hash) db.add(user) db.flush() # 拿到自增 id，但不提交 Profile(user_id=user.id).save(db) PointAccount(user_id=user.id, balance=0).save(db) async_notify_welcome(user.id) return user

flush()和commit()的区别值得说一句。flush 把 SQL 发到数据库但不提交事务，能拿到自增主键，后续关联表可以用；commit 才真正提交。在事务代码块里用 flush，块结束时自动 commit，这样几条 insert 就在同一个事务里，中途失败全部回滚。

3.3 并发场景下的幂等与限流处理

注册接口天然不是幂等的——同一个请求发两次，理想结果是第一次成功、第二次返回"已存在"。这个语义要靠唯一索引来实现，不能靠应用层的判断。但还有一层要处理：用户手抖连点两次提交，前端并发发了两个一样的请求，两个都通过了预检查，然后一个成功一个撞索引报错。对用户来说，看到的是"注册成功了但页面弹了个错误"。

我的处理是在前端加提交按钮置灰，后端加一个短期的请求去重。去重键用register:{username_lower}或者客户端传来的幂等 token，放 Redis，过期时间 5 秒。第二次请求进来发现键存在，直接返回一个"处理中"的状态码，让前端轮询或者提示稍候。这个方案简单有效，成本也就一次 Redis 读写。

def acquire_register_lock(client, key: str, ttl: int = 5) -> bool: # SET NX EX 原子操作，同一个 key 在 ttl 内只能成功一次 return bool(client.set(f"lock:register:{key}", "1", nx=True, ex=ttl))

限流这块，注册接口绝对要限。不限的话，一个脚本一分钟能刷出几万个账号，把库撑爆之外还会污染后续的数据分析。我一般按 IP 和按设备指纹双维度做：单 IP 每小时不超过 20 次注册尝试，单设备每天不超过 5 个账号。超出直接返回 429，同时记一条风控日志。窗口用滑动窗口比固定窗口好，固定窗口在边界上会出现双倍流量，也就是 00:59 刷满、01:00 再刷满，实际速率是限制值的两倍。

def check_register_rate(client, ip: str, limit: int = 20, window: int = 3600) -> bool: key = f"rate:reg:{ip}:{int(time.time()) // window}" pipe = client.pipeline() pipe.incr(key) pipe.expire(key, window * 2) # 多留一个窗口，避免边界丢计数 count, _ = pipe.execute() return count <= limit

至于压测验证，我通常写一个小脚本，用 50 个并发对同一个用户名发起注册，断言只有一个成功、其余全部返回 40901，且数据库里只有一条记录。这个测试能一次性验证唯一索引、异常处理、事务回滚三件事，值得放进回归用例里。

seq 1 50 | xargs -P 50 -I{} curl -s -X POST http://127.0.0.1:8000/api/v1/register \ -H "Content-Type: application/json" \ -d '{"username":"race_test","email":"racer{}@domain.test","password":"Abc12345"}' \ | grep -c '"code":0'

期望输出是 1。如果输出大于 1，说明唯一索引没生效或者数据库隔离级别有问题；如果输出是 0，去看日志里的报错，大概率是邮箱也撞了唯一索引，把邮箱改成随请求变化的值即可。

3.4 接口自测清单与验证方法

写完之后我会按清单过一遍，下面这些是必测项：

自测时别只看接口返回，一定要去数据库里select一下，确认落库的 username 保留了原始大小写、username_lower 是归一化后的值、password_hash 长度正常且不是明文。这三个字段是最容易写错的。

4. 常见问题与排查技巧实录

4.1 高频问题速查表

下面这张表是我这几年处理注册接口问题攒下来的，按出现频率排序，遇到问题可以先照着对一遍：

4.2 几个印象深刻的坑

第一个坑是软删除和唯一索引的冲突。当时产品要求"用户注销后 90 天内可以用原用户名重新注册"。我们的实现是 status 置 0 软删除，唯一索引建在 username_lower 上。结果发现注销账号的用户名还是占着位置，注册报重复。第一反应是把索引改成部分索引（WHERE status = 1），改完后发现历史注销记录和新注册的活账号之间不冲突了，但两个已注销账号之间还是不能重名——这个反而是对的，毕竟历史数据要保持可追溯。这类问题一定要在需求阶段就把语义定清楚，不要等到线上出问题再补。

第二个坑是 bcrypt 的 72 字节限制。有个用户的密码是中文加长串，UTF-8 编码后超过 72 字节，bcrypt 静默截断。表现出来的现象是"我用密码 A 登录成功，用密码 B 也登录成功"，因为 A 和 B 的前 72 字节一样。这个问题极其隐蔽，靠功能测试根本发现不了，后来是写了个模糊测试才暴露出来。现在的做法是校验层直接限制字符数，同时把长度上限写进接口文档。

第三个坑是事务里的异步通知。原来代码把发欢迎邮件的调用写在事务块里面，邮件服务超时 3 秒，导致数据库事务也挂了 3 秒，注册接口 P99 直接飙到 4 秒。更糟的是邮件服务偶发 500，导致整个注册回滚——用户明明信息都填对了，就是注册不上。改成事务提交后异步执行之后，接口耗时立刻降到 200 毫秒以内。

第四个坑是日志泄露。某次排查问题，同事在注册接口加了一行打印完整请求体的日志，日志平台是所有人可见的，等于把一批明文密码写进了公共系统。虽然很快删掉了，但这批用户还是通知改密了。现在的规范是：涉及敏感字段的日志一律用统一的脱敏工具，不靠人自觉。

4.3 上线前的自检清单

每次上线前我会把这几条过一遍，缺一条不发版：

• 唯一索引已在生产库确认存在，且定义与开发库一致（不同环境的索引定义不一致是最难查的问题之一）。
• 密码哈希的实现与配置参数（cost、算法）和生产一致，没有因为性能测试临时调低忘记改回。
• 事务边界覆盖所有写表操作，异常分支都有 rollback。
• 限流阈值按预估流量的 3 倍设，避免正常用户被误伤，同时要能在配置中心动态调整。
• 日志里没有任何明文密码、验证码、完整手机号。
• 接口在无缓存、冷启动、数据库高负载三种状态下都测过。
• 有一份可执行的并发测试脚本，能一键验证唯一性。
• 错误码有统一的文档，前端能照着做提示文案，不靠猜。

5. 安全加固与后续扩展

5.1 防刷策略的层次设计

限流只是第一层。真正做起来，注册接口的防护要分几层叠。

最外层是接入层限流，按 IP、按 UA、按接口路径做粗粒度限流，拦掉最粗暴的脚本。这一层的阈值可以设得比较宽，主要目的是削峰而不是精确定位。

中间层是业务层限流，按业务维度计数。比如同一手机号 24 小时内最多 3 次验证码、同一设备指纹每天最多注册 2 个账号、同一邮箱域名短时间内大量注册要告警。这层需要设备指纹或手机号作为键，比 IP 准确得多，因为 IP 可以轻易切换，设备指纹成本高得多。

最内层是风控信号。注册时收集一些非强制字段：请求间隔、鼠标轨迹（如果前端有）、UA 与设备类型是否匹配、注册时间是否集中在凌晨。这些信号单独看都不能定性，组合起来做规则打分，超过阈值就触发人工审核或者要求额外验证。我不建议一开始就上复杂的规则引擎，先把最明显的几个特征（同 IP 高频、UA 异常、注册时间异常）做成简单规则，跑一段时间看误杀率，再逐步加特征。

5.2 验证码的接入时机与方式

验证码不要一上来就加，会劝退一部分正常用户。我的做法是分阶段：常规请求不要求验证码，当某个 IP 或设备在短时间内失败次数超过阈值，下一次请求返回一个"需要验证"的标记，前端弹图形验证码或滑块。这种"按需触发"的方式对正常用户几乎无感，对脚本则提高了成本。

验证码校验要注意两点。一是验证码必须一次性使用，校验通过立即删除，否则同一个验证码可以被重放。二是验证码的 key 要绑定业务场景，注册的验证码不能用于登录，避免跨场景复用。这两点听起来是常识，但我在代码评审里见过不少实现只做了"存进去、取出来比对"，没做删除，也没做场景隔离。

5.3 接口的后续演进方向

注册接口上线不是终点，后面大概率要接这些东西：

邮箱或手机号验证。注册时先落一个未激活状态，用户点链接或输验证码后置为激活。这样能过滤掉一部分乱填信息的账号，代价是多一个状态字段和一套激活流程，接口契约里要预留 status 字段。

第三方账号绑定。这块的设计要点是解耦：不要把第三方登录逻辑塞进注册接口，而是单独做一个"绑定"接口，注册和绑定共享同一套用户创建的服务方法。我见过把微信登录、手机号注册、邮箱注册写在一个巨型 if-else 里的代码，后来加一个渠道就要动整个方法，改一次错一次。

邀请与渠道归因。注册时带上 invite_code，落库后触发一次归因计算，把邀请关系记到关系表里。这块要注意防自邀（自己邀请自己），校验时比对注册 IP、设备指纹、支付账号，至少拦住最明显的刷单。

账号合并。当用户先用邮箱注册、后来又用手机号注册，系统会认为这是两个账号。产品上要么禁止（提示"该手机号已绑定其他账号"），要么支持合并。合并是典型的复杂功能，涉及数据迁移、冲突处理、历史订单归属，不要在注册接口里顺手做，单独开一个流程。

我在实际项目里的体会是，注册接口的代码量从来不是问题，难的是把边界想全。每次加新渠道、新校验、新风控，都要回头检查一遍唯一性、事务、限流这三件事有没有被破坏。养成的习惯是：改完注册相关的任何代码，先跑一遍那个 50 并发的脚本，再看一眼唯一索引定义，最后确认日志里没有敏感信息。三步走完，基本能挡住八成的问题。