必须抛异常，不能自动转成默认值或截断；因为@Property是属性访问接口而非数据清洗入口，静默修正会掩盖业务意图、导致下游逻辑拿到意料之外的值。
python 数据校验放 @property 里，值不合法时抛异常还是静默修正？
放 @property 的 setter 里做校验，最直接的分歧是：遇到非法输入，该不该立刻 raise ValueError？答案是——**必须抛异常，不能自动转成默认值或截断**。因为 @property 是属性访问接口，不是数据清洗入口；用户调用 obj.name = " " 时，预期是“赋值成功”或“明确失败”，而不是“你偷偷给我塞了个空字符串”。静默修正会掩盖业务意图，导致下游逻辑拿到意料之外的值。
- 常见错误现象：
obj.age = -5后obj.age变成0，但调用方完全不知道被改了 - 使用场景：适合强契约场景，比如 ORM 模型字段、配置类、DTO，要求写入即校验
- 性能影响极小，setter 本身开销有限；但若校验逻辑重（如正则匹配长文本），要注意避免在高频属性访问中触发
和 dataclasses.field(default_factory=...) 或 Pydantic 的 Field(..., validator=...) 比，@property 校验缺什么？
@property 校验只管单次赋值，不参与初始化、序列化、批量设置，也不提供统一错误收集能力。比如 MyClass(name="", age=-1) 创建实例时，@property 根本不执行——setter 只在 = 赋值时触发。这意味着初始化阶段的数据漏洞完全漏检。
- 参数差异：
dataclass的__post_init__或 Pydantic 的validator在实例化时就跑，@property不行 - 兼容性问题：用
vars(obj)或dataclasses.asdict()时，@property定义的校验逻辑不会被识别为“字段”，容易漏传 - 错误信息分散：每个 setter 自己
raise，没法像 Pydantic 那样聚合多个字段错误一起返回
@property 校验和类型注解（str, int）冲突怎么办？
类型注解只是提示，运行时不强制；而 @property setter 是实际拦截点。但二者语义可能打架：比如注解写 age: int，但 setter 却接受 "25" 并转成 int。这会让类型检查器（如 mypy）报错，也违背“标注即契约”的直觉。
- 推荐做法：setter 严格按类型注解来——
age只收int，字符串输入应由上层处理，不在此处兜底 - 容易踩的坑：为了“方便”在 setter 里做类型转换，结果让 mypy 失效，且隐藏了上游数据来源问题（比如 json 解析没设
object_hook） - 如果真需要柔性的类型适配，应该放在初始化层（如
__init__或工厂方法），而不是属性层
什么时候该放弃 @property 校验，改用专用校验函数？
当校验逻辑依赖外部状态（如数据库查重）、涉及 IO、或需要批量验证多个字段时，@property 就不合适了。它的本质是“单字段、同步、无副作用”的访问控制，强行塞网络请求或事务操作，会污染对象模型，也让单元测试难以 mock。
立即学习“Python免费学习笔记（深入）”；
- 典型场景：用户注册时校验邮箱是否已存在、订单创建时核对库存与价格一致性
- 实操建议：把这类逻辑抽成独立函数，比如
validate_order_payload(payload: dict) -> list[str]，返回错误列表，由调用方决定如何处理 - 性能提醒：
@property被频繁读取时（如模板渲染循环中），带 IO 的校验会拖慢整个流程，必须剥离
真正难的不是写个 if value ，而是想清楚校验发生的时机、责任边界和失败后的协作方式。属性层校验只是冰山一角，底下连着初始化、序列化、API 输入、测试可测性——动一处，得看全链路是否还稳。