应将重复校验逻辑抽成独立函数（如validate_username），由函数自身抛出异常而非返回布尔值；数据库校验需拆分为格式与唯一性两步；装饰器仅用于参数来源固定的入口，避免过度抽象；Pydantic可轻量用于非FastAPI场景，注意strict模式；测试中复用业务校验函数并封装断言以提升可读性与定位效率。
校验逻辑重复写在多个函数里怎么办
把校验代码复制粘贴到每个需要的地方，改一处漏十处，是 Python 里最常见也最危险的重复。核心解法不是“少写”，而是“只定义一次，多处调用”。
常见错误现象：if not isinstance(x, str)、if len(data) == 0、if not re.match(r'^[a-z]+$', name) 这类判断在 create_user、update_profile、export_report 里反复出现，但参数名、提示语、抛错类型还不一致。
- 统一抽成独立函数，比如
validate_username，输入是原始值，输出是清洗后值或明确抛出ValueError - 不要返回
True/False让调用方再if not ... raise—— 验证函数自己负责报错，语义更清晰 - 如果校验需访问数据库（如查重），别塞进纯函数；拆成
check_username_format+check_username_unique，职责分明
用装饰器做参数校验容易踩哪些坑
装饰器看着干净，但实际用起来很容易掉进“过度抽象”和“错误掩盖”的坑里。
使用场景：API 视图函数、CLI 命令入口、批量处理任务的主函数——这些地方参数来源固定、校验规则稳定。
立即学习“Python免费学习笔记（深入）”；
- 别在装饰器里吞掉原始异常，比如捕获
ValidationError后又抛RuntimeError，会丢失上下文 - 装饰器接收的校验规则如果是字典（如
{'name': 'required,str,min=2'}），解析逻辑一复杂就难调试，不如直接调用函数来得直白 -
@validate_params(name=str, age=int)这种写法看似简洁，但无法表达“age 必须大于 0”，真要加业务逻辑，最后还是得退回到显式调用
Pydantic Model 在非 FastAPI 场景下怎么轻量用
很多人以为 Pydantic 只配 FastAPI，其实只要装了 pydantic（v2 起叫 pydantic-core），它就是个极快的运行时校验+结构化工具，不依赖 Web 框架。
性能影响：单次校验比手写 if 慢一点，但差距在微秒级；好处是自动类型转换、字段别名、嵌套校验全都有，且错误信息可读性强。
- 不用继承
BaseModel也能用：直接调model_validate或model_validate_json，适合临时校验字典或 JSON 字符串 - 避免为简单场景定义完整 Model：比如只校验一个邮箱，用
EmailStr类型注解配合validate_call更轻——@validate_call(config={'arbitrary_types_allowed': True})+ 参数注解email: EmailStr - 注意
strict=True模式：默认会尝试类型转换（"123"→int），业务敏感时务必显式关掉，否则可能掩盖数据污染
单元测试里校验逻辑重复怎么破
测试代码里反复写 assert isinstance(resp.data, dict)、assert 'id' in resp.data，不是“测试写得多”，是校验没抽象。
最容易被忽略的一点：测试里的校验，目标不是“跑过”，而是“失败时快速定位问题”。所以复用要兼顾可读性和错误提示精度。
- 把通用断言抽成函数，比如
assert_api_success(resp)，内部用assert resp.status_code == 200+assert 'data' in resp.json()，但别塞太多逻辑进去 - 别用
assert resp.json() == expected做全量比对——字段顺序、空字段、时间戳精度都会导致失败，改用deepdiff或只校验关键路径：assert resp.json()['data']['user']['name'] == 'alice' - 测试中复用业务校验函数（比如上面抽出来的
validate_username）比自己再写一套更可靠——校验逻辑本身也是被测对象
