校验函数应抛出异常而非返回布尔值，成功时静默返回；推荐用装饰器封装通用规则，Pydantic适用于数据结构层面校验，避免在__init__中校验。

校验函数要不要返回布尔值

很多初学者一写校验就直接 return True 或 return False，结果后续要加错误提示、日志或中断流程时，不得不把所有调用点全改一遍。校验逻辑真正的价值不在“对错判断”，而在“错在哪”和“要不要继续”。建议统一用异常驱动：校验失败时抛出 ValueError 或自定义异常（如 ValidationError），成功则静默返回。这样既避免重复写 if not validate_xxx(): raise ...，也方便上层统一捕获处理。

• 不要写 if not is_email_valid(email): raise ValueError("邮箱格式错误")
• 直接写 validate_email(email)，内部校验不通过就 raise ValueError("邮箱格式错误")
• 多个校验串联时，顺序执行即可，无需每步都判布尔值

用装饰器封装通用校验规则

比如参数非空、长度限制、枚举值检查——这些逻辑高度重复，但硬编码在每个函数里会迅速失控。用装饰器抽离是最轻量的解法，且不侵入业务逻辑。关键点是：装饰器接收校验配置（如 required=True、max_length=50），再动态生成校验行为，而不是为每个规则写一个装饰器。

示例：@validate_arg("username", required=True, min_length=3, max_length=20) 可自动检查 username 是否存在、是否过短或过长；若校验失败，抛出带字段名的异常，便于定位。

• 避免为每个字段写单独的校验函数，如 check_username()、check_phone()
• 装饰器内部用 inspect.signature 获取参数名和值，不依赖调用约定
• 注意装饰器不要修改原函数的 __name__ 和 __doc__，否则调试和文档工具会失效

Pydantic 模型校验适合什么场景

当校验逻辑集中在数据结构层面（如 API 请求体、配置字典、数据库记录反序列化），Pydantic 是比手写 if-else 更可靠的选择。它天然支持类型约束、嵌套校验、默认值填充和错误聚合——但别把它当成万能胶水：如果校验需要查数据库、调外部接口或含复杂业务规则（如“用户A不能给用户B发消息，除非他们互相关注”），就该退回到显式函数，而不是硬塞进 Field(..., validator=...)。

• 适合：字段类型、范围、正则、必填/可选、嵌套模型结构
• 不适合：跨字段逻辑（如密码和确认密码一致）、运行时依赖状态的判断
• model.validate() 失败时抛 ValidationError，错误信息自带路径（如 body -> user -> email），比手拼字符串强得多

为什么校验逻辑别放在类的 __init__ 里

看似方便——构造对象时顺手校验，但实际埋了三个坑：一是无法复用（校验逻辑被绑定在实例创建路径上）；二是掩盖真实意图（User(name="") 报错，你不知道是构造逻辑问题还是数据问题）；三是阻碍测试（想测校验本身，还得先绕过 __init__）。更合理的是把校验拆成

独立函数或方法，比如 User.validate_data(data: dict) -> None，让使用者明确选择何时校验、如何处理失败。

• 不要在 __init__ 中调用 self._validate_name()
• 提供 from_dict(cls, data: dict) 类方法，内部调用校验再实例化
• 若必须保证实例始终合法，用 __post_init__（dataclass）或 model_validator（Pydantic v2），但依然要和业务校验分离

校验代码最容易被忽略的，其实是错误上下文的完整性——同一个 ValueError("格式错误") 在 10 个地方抛出，你根本分不清是哪个字段、哪次调用、什么输入导致的。留好字段名、原始值、触发条件，比省那几行代码重要得多。