JWT 401 错误主因是编码器未生效：若 PHP 无 openssl 扩展，LexikJWTBundle 会静默回退至 base64 编码器导致签名非法；需确认 lexik_jwt_authentication.encoder 参数值为 lexik_jwt_authentication.encoder.openssl，并确保私钥路径绝对且可读。
JWT token 生成后 401 Unauthorized？检查 lexik_jwt_authentication.encoder 配置
绝大多数 401 错误不是因为路由或防火墙没配，而是密钥编码器根本没生效。LexikJWTBundle 默认用 openssl 编码器，但如果你的 PHP 没装 openssl 扩展（比如 Alpine 容器里默认不带），它会悄悄 fallback 到 base64 编码器——后者无法生成合法 JWT 签名，所有请求全 401。
验证方式：运行 php bin/console debug:container --parameter=lexik_jwt_authentication.encoder，输出必须是 lexik_jwt_authentication.encoder.openssl。如果不是：
- 确认
ext-openssl已启用：php -m | grep openssl - 强制指定编码器，在
config/packages/lexik_jwt_authentication.yaml加：lexik_jwt_authentication: encoder: service: lexik_jwt_authentication.encoder.openssl - 私钥路径必须绝对且可读：
openssl_pkey_get_private()会静默失败，建议用file_exists()+is_readable()在 kernel boot 阶段校验
Invalid credentials 却没进 UserProvider？查 loadUserByUsername 是否被调用
这个错误看似是密码错，实则常因用户加载阶段就中断。LexikJWTBundle 不直接校验密码，它只解 token、取 username 字段，再交给 Symfony 的 UserProviderInterface::loadUserByUsername() 去查库。如果这里抛异常或返回 null，就会直接报 Invalid credentials，连密码比对环节都进不去。
常见断点：
-
loadUserByUsername()方法里写了dd()或dump()，但开发环境未开启 profiler，导致“看起来没执行” - token 中的
username字段名和user_identity_field配置不一致，默认是username，但你的 token 可能发的是email—— 必须同步改配置：lexik_jwt_authentication: token_extractors: authorization_header: identity_field: email - 数据库查不到该用户，但
UserProvider没 throwUsernameNotFoundException，而是返回null，Bundle 会统一转成Invalid credentials
前端传 Bearer token 但服务端收不到？确认 Authorization header 未被 Web 服务器剥离
Nginx/Apache 默认会过滤掉带下划线或大小写混搭的 header，Authorization: Bearer xxx 中的 Authorization 首字母大写，某些 Nginx 配置（尤其用了 underscores_in_headers on）会干扰解析；更常见的是 Apache 的 mod_rewrite 或 FastCGI 配置丢失了 header。
快速定位：
- 在 controller 里加
var_dump($request->headers->all());，看authorization键是否存在 - Nginx 需确保有：
location ~ ^/api { proxy_set_header Authorization $http_authorization; proxy_pass http://php-fpm; - Apache + mod_php：确认
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1已启用 - Docker 环境下，宿主机和容器时区不一致可能导致 token
exp时间校验失败，表现也是 401，但日志里看不到明显线索
刷新 token 时 The token has been blacklisted？别直接删数据库记录
LexikJWTBundle 的黑名单机制依赖 JWTCreatedEvent 和存储驱动（如 Doctrine ORM）。很多人以为“删掉 blacklist 表里的旧 token 就行”，但实际黑名单校验发生在 token 解码后、用户认证前——此时 token 还没解析出 jti，Bundle 是靠完整 token 字符串做哈希比对的。
所以问题常出在这儿：
- 你清空了黑名单表，但缓存没清（比如用了 Redis 驱动），
cache.jwt_blacklist里还存着旧 token 哈希 - 多个实例共用一个黑名单存储，但某台机器的时钟快了 2 分钟，导致它把还没过期的 token 提前加入黑名单
- 自定义
JWTCreatedEvent监听器里手动调了$event->markAsInvalid()，但没 throw 异常，结果 token 被生成又立刻拉黑
真正安全的刷新逻辑：用 RefreshTokenCommand 或手动调 JWTManager::create() 生成新 token，并确保旧 token 的 jti 明确写入黑名单——别碰原始 token 字符串本身。黑名单本质是「已知失效的 jti 列表」，不是「原始 token 字符串集合」。
