黑名单表设计要支持快速查询和灵活扩展
核心是建一张
user_blacklist表，不要只存用户 ID 就完事。实际业务中常需区分拉黑原因、生效时间、操作人、是否临时封禁等。推荐字段包括：
user_id（被拉黑者）、
operator_id（操作人）、
reason（枚举或短文本）、
expires_at（NULL 表示永久）、
created_at、
status（如 'active' / 'revoked'）。索引必须加在
user_id和
status上，否则每次登录校验都可能全表扫描。
登录验证时如何高效拦截黑名单用户
不是在应用层查完用户再查黑名单表——那样至少两次查询，还可能有竞态。更稳妥的是在认证 SQL 中直接 LEFT JOIN 或子查询过滤。例如：
SELECT u.* FROM users u
WHERE u.username = ?
AND NOT EXISTS (
SELECT 1 FROM user_blacklist b
WHERE b.user_id = u.id
AND b.status = 'active'
AND (b.expires_at IS NULL OR b.expires_at > NOW())
);注意两点：一是
NOT EXISTS比
NOT IN更安全（避免子查询返回 NULL 导致整条结果消失）；二是
expires_at > NOW()必须写进子查询条件，否则过期记录仍会阻断匹配。
拉黑操作必须带事务和审计日志
一次拉黑本质是多步动作：插入黑名单记录 + 可能清空该用户 session + 记录操作日志。这三者必须包在同一个事务里，否则出现「表里写了黑名单但 session 还活着」的漏放情况。常见错误是用 ORM 分多次提交，或者把日志写到文件/其他数据库导致事务不一致。建议：
所有操作统一走 MySQL 事务，日志也写入同一库的admin_audit_log表
user_blacklist表主键用
(user_id, created_at)联合唯一，防止重复拉黑 提供解封接口时，不要物理删除记录，而是更新
status = 'revoked'，保留可追溯性
注意缓存与黑名单状态的一致性问题
如果登录流程用了 Redis 缓存用户信息（比如
user:123），那黑名单变更后，这个缓存不会自动失效。用户可能刚被拉黑，但缓存里的旧数据还在，导致拦截失败。解决方案只有两个： 每次登录时，先查黑名单表（轻量级查询，有索引支撑），再决定是否读缓存； 拉黑/解封操作后，主动
DEL user:{user_id}，但要注意分布式环境下操作必须幂等，建议用 Lua 脚本封装删除逻辑。
别指望靠缓存过期时间兜底——5 分钟内被拉黑的用户照样能登录，风控场景下这就是漏洞。
