在Java开发中，最轻量且可控性最高的方案，莫过于在setter方法内部直接进行校验和类型检查。这种方式无需依赖框架、无需折腾反射、也无需额外配置，对于ID、金额、状态码等关键字段，手动校验尤为可靠。

在setter方法中嵌入校验逻辑

将校验逻辑直接集成到属性赋值处，确保每次修改都经过验证。具体实现方式如下：

• 使用instanceof或Class.isAssignableFrom()确认传入值的类型是否符合预期
• 对非空、数值范围、格式等进行显式判断，不符合规则则抛出IllegalArgumentException
• 注意在setter中避免调用外部服务或执行耗时操作，确保轻量和可预测性

支持泛型与继承关系的类型校验策略

当属性声明为父类或接口时（例如Number value），setter中可以进一步限定子类型。听起来复杂？其实有办法：

• 只允许BigDecimal和Long，排除Double以避免精度丢失
• 先通过Objects.requireNonNull()防止null，再用getClass()进行白名单匹配
• 对于集合类属性，可以检查其泛型实际类型，借助ParameterizedType解析，但仅在构造时已知类型的情况下可行

结合final字段与构造器实现不可变校验

尽管setter校验有效，但无法阻止通过反射或序列化绕过。若需更稳健的方案，可采取以下措施：

• 将字段声明为private final
• 将所有校验逻辑集中在构造器中，setter仅在构建阶段使用（或直接省略setter）
• 如果业务场景允许后期修改，可采用“带校验的Builder模式”，将setter逻辑封装到builder的withXxx()方法中

规避常见陷阱

手动校验时容易踩的几个坑包括：

• 将子类实例传入父类setter后，若后续方法依赖子类特有字段，可能引发NullPointerException。应在校验时明确要求具体类型
• 自动拆箱导致的NullPointerException，例如对Integer调用intValue()前未判null
• 浮点数比较使用==而非Double.compare()或误差容忍判断

坦白讲，这种写法虽然质朴，但却是最不易出错的方案。可以说，它在代码质量与可维护性之间达到了很好的平衡。