oauth2passwordrequestform必须通过表单提交（content-type: application/x-www-form-urlencoded或multipart/form-data），不可发送json，否则将返回422错误；它依赖python-multipart解析，且字段名严格限定为username和password。
OAuth2PasswordRequestForm必须用表单提交，不能发JSON
FastAPI的OAuth2PasswordRequestForm依赖python-multipart解析请求体，它只认application/x-www-form-urlencoded或multipart/form-data。如果你用fetch或axios发JSON（Content-Type: application/json），会直接报422 Unprocessable Entity，错误信息里明确提示username和password字段缺失。
实操建议：
- 前端登录请求必须用
FormData构造，或设置Content-Type为表单类型 - Postman中选择
Body → form-data，填username和password两个key - 不要在Pydantic模型里套
OAuth2PasswordRequestForm——它本身就是专为表单设计的依赖项
tokenUrl路径必须与/login或/token端点严格一致
OAuth2PasswordBearer(tokenUrl="token")里的tokenUrl是相对路径，Swagger UI会据此生成“Authorize”按钮的跳转地址。如果后端实际暴露的是@app.post("/login")，但tokenUrl写成"token"，点击认证按钮就会404；反之亦然。
常见错误现象：
- Swagger UI点“Authorize”弹窗后输入账号密码，点“Authorize”没反应——大概率是
tokenUrl和真实端点不匹配 - 手动调用
/token返回405 Method Not Allowed——检查是否误把@app.post写成了@app.get - 生产环境Nginx反代后路径被重写，需确保
tokenUrl指向代理后的可访问路径（如"/api/v1/token"）
JWT签发时必须校验用户存在且密码正确，不能只查数据库
很多初学者直接从fake_users_db取用户后就返回token，跳过了verify_password调用。这会导致任意密码都能登录——因为哈希比对逻辑被绕过。
关键步骤顺序不能错：
- 先用
form_data.username查用户，查不到就raise HTTPException(400, "Incorrect username") - 再用
pwd_context.verify(form_data.password, user.hashed_password)校验密码，失败则统一返回400（避免泄露账号是否存在） - 最后才调用
create_access_token(data={"sub": user.username})，其中sub（subject）是JWT标准字段，代表用户标识
注意：SECRET_KEY绝不能硬编码，必须从环境变量读取；ALGORITHM推荐"HS256"，但若用"RS256"需配套私钥签名、公钥验签。
Depends(oauth2_scheme)会自动提取Bearer Token，但不验证内容
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")只做一件事：从Authorization: Bearer xxx请求头里取出xxx字符串，并作为str传给后续函数。它**不解析JWT、不校验签名、不过期检查**——这些全得你自己用jwt.decode()实现。
典型漏掉的环节：
- 没捕获
JWTError异常，导致token无效时抛500而非401 - 没检查
exp字段，过期token仍被放行 - 没验证
sub对应用户是否仍启用（如disabled == True）
所以get_current_user依赖项里必须包含完整的JWT decode + 验证逻辑，不能只返回原始token字符串。
最易被忽略的一点：Bearer Token的token_type字段在响应里必须小写"bearer"（RFC 6750规定），写成"Bearer"或"BAREER"会导致某些客户端（如旧版curl）拒绝携带该token。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
