如何校验SQL查询参数_通过Schema验证确保输入合法-SQL-PHP中文网

SQL参数校验不能只靠后端if判断，因前端可绕过、字符串拼接和ORM误用会使校验失效；应将校验下沉至数据契约层，用Pydantic等Schema工具在运行时强制约束类型、范围、枚举、空值及隐式转换，并统一处理错误提示。

如何校验sql查询参数_通过schema验证确保输入合法

SQL参数校验为什么不能只靠后端if判断

因为绕过前端、拼接字符串、ORM误用都会让if形同虚设——真正能守住边界的，是把校验逻辑下沉到数据契约层。Schema不是文档，是运行时可执行的约束声明。

常见错误现象：TypeError: expected string, got None、psycopg2.DataError: invalid input syntax for type integer，这类报错其实早该在参数进SQL前就拦截，而不是等数据库吐出错误再兜底。

使用场景：API接口接收user_id、status、created_after等查询参数，需确保类型、范围、格式合法
不要在SQL拼接前做int(param)强转——失败就炸，且无法统一处理错误提示
Schema验证必须覆盖空值、类型隐式转换（如"1"→1）、枚举白名单（如status只能是"active"/"inactive"）

用Pydantic v2定义查询参数Schema最简写法

Pydantic是目前Python生态里对查询参数校验最自然的方案，不依赖FastAPI也能用，核心是把参数结构变成可验证的数据模型。

示例：一个带分页和状态过滤的用户查询

from pydantic import BaseModel, Field, field_validator
from typing import Optional, Literal
<p>class UserQuerySchema(BaseModel):
user_id: Optional[int] = Field(None, ge=1)  # >=1，None允许为空
status: Optional[Literal["active", "inactive"]] = None
page: int = Field(1, ge=1)
size: int = Field(20, ge=1, le=100)</p><pre class="brush:php;toolbar:false;">@field_validator("user_id")
def validate_user_id(cls, v):
    if v is not None and v = 1")
    return v

Field直接声明约束（ge=greater than or equal），比写@validator更轻量
Literal强制枚举，传"pending"会直接报Input should be 'active' or 'inactive'
别用Optional[str]配default=None——Pydantic v2默认就允许None，重复写反而容易漏掉None校验分支
如果用Flask或纯WSGI，调用UserQuerySchema.model_validate(request.args.to_dict())即可，失败抛ValidationError

PostgreSQL/MySQL字段类型和Schema怎么对齐

数据库字段定义（比如status VARCHAR(10)）不等于校验规则。VARCHAR能存任意字符串，但业务上可能只接受两个值——Schema要补上这层语义。

id SERIAL → Schema用int + ge=1，别信“数据库自增就安全”，恶意请求仍可传-999
created_at TIMESTAMPTZ → 查询参数created_after建议用datetime类型，配合strptime解析ISO格式（"2024-05-20T09:30:00Z"），别接受"2024/05/20"这种模糊格式
MySQL的TINYINT(1)常被当布尔用，但实际能存0~255——Schema必须用Literal[0, 1]或bool并指定coerce行为，否则2会静默入库
注意时区：数据库存UTC，但用户传"2024-05-20"默认是本地时区，Schema层就要决定是转UTC还是拒绝非ISO带时区格式

校验失败后怎么返回友好错误而不暴露SQL细节

直接把Pydantic的ValidationError堆栈打给前端，等于告诉攻击者你用了什么库、字段名是什么、甚至表结构。必须重写错误输出。

捕获ValidationError后，用exc.errors()提取字段+错误类型，映射成业务语言：{"user_id": "必须是正整数"}，而非"Input should be greater than or equal to 1"
不要在错误消息里出现SQL、query、column、table等词，避免泄露数据模型
对422 Unprocessable Entity响应体，只包含field、message、code三个键，其他一概不加——前端按这个契约渲染，后端不额外扩展
日志里可以记完整exc.json()，但响应体必须脱敏。这点容易被忽略：开发时图省事直接return str(exc)，上线就成漏洞

事情说清了就结束