校验函数应抛出异常而非返回布尔值，成功时静默返回；推荐用装饰器封装通用规则，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=...)。
立即学习“Python免费学习笔记（深入）”；
- 适合：字段类型、范围、正则、必填/可选、嵌套模型结构
- 不适合：跨字段逻辑（如密码和确认密码一致）、运行时依赖状态的判断
-
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 个地方抛出，你根本分不清是哪个字段、哪次调用、什么输入导致的。留好字段名、原始值、触发条件，比省那几行代码重要得多。 
