django 4.2 的 checkconstraint 不能直接校验浮点数精度，因其依赖数据库 check 表达式，而 postgresql/mysql 对 float 类型存在二进制精度误差；应改用 decimalfield 配合数值字面量约束，如 amount__gte=0.01，并在 meta.constraints 中正确定义，且需注意迁移时数据验证与数据库兼容性。
为什么Django 4.2的CheckConstraint不能直接校验浮点数精度？
Django 4.2 的 CheckConstraint 确实支持在数据库层强制数值范围，但它依赖底层数据库的 CHECK 表达式能力，而 PostgreSQL/MySQL 对浮点数比较存在隐式精度问题——比如 price > 0.0 在某些情况下可能因二进制表示误差意外放行 -0.0 或极小负值。这不是 Django 的 bug，而是 SQL 引擎对 REAL/DOUBLE PRECISION 类型的固有限制。
实际场景中，你更常需要的是「非负且有业务上限」，比如商品价格必须在 0.01 到 99999.99 之间。这时应优先用数据库原生 decimal 类型配合严格 CHECK，而非 float。
- 用
models.DecimalField(max_digits=8, decimal_places=2)替代FloatField，确保存储精度可控 - 在
CheckConstraint中直接写数值字面量（如price__gte=0.01），Django 会将其转为 SQL 的CHECK (price >= 0.01) - 避免在 CHECK 中使用 Python 表达式或函数调用（如
round()），数据库不认这些
如何在Model中正确定义CheckConstraint防止负数和超限？
关键不是加约束本身，而是约束定义的位置和迁移时机。必须把 CheckConstraint 放在 Meta.constraints 里，并确保字段类型已明确支持数值比较。
例如，一个订单金额字段：
class Order(models.Model):
amount = models.DecimalField(max_digits=10, decimal_places=2)
class Meta:
constraints = [
models.CheckConstraint(
check=models.Q(amount__gte=0.01) & models.Q(amount__lte=999999.99),
name='order_amount_range'
)
]
-
name参数必须唯一且符合数据库标识符规则（不能含空格、特殊字符），否则 migrate 失败报错django.db.utils.ProgrammingError: constraint "order_amount_range" of relation "myapp_order" does not exist - 如果表已存在数据，Django 4.2 默认不会验证旧数据是否满足新约束——需手动执行
ALTER TABLE ... VALIDATE CONSTRAINT（PostgreSQL）或先清理数据再迁移 - MySQL 8.0.16+ 支持 CHECK，但早期版本会静默忽略，务必检查
SHOW CREATE TABLE myapp_order确认约束是否真实写入
为什么save()时没报错但数据库插入却失败？
这是最典型的认知偏差：以为模型层校验 = 数据库层校验。Django 的 full_clean() 和表单验证默认不触发数据库 CHECK 约束，只有真正执行 INSERT 或 UPDATE 时才会由数据库抛出异常。
典型错误流程：用户提交 amount=-5.0 → 表单 clean() 没配 min_value → form.save() 调用成功 → 实际执行 SQL 时 PostgreSQL 返回 IntegrityError: new row for relation "myapp_order" violates check constraint "order_amount_range"。
- 解决方法一：在 Model 的
clean()方法里手动复现 CHECK 逻辑，比如if self.amount - 解决方法二：在表单字段中显式设
min_value=0.01和max_value=999999.99，这样form.is_valid()就能拦截 - 不要依赖
default或blank=True绕过校验——CHECK 是硬性防线，绕过只会让数据不一致更隐蔽
PostgreSQL vs MySQL在CheckConstraint上的关键差异
同一段 Django 约束代码，在不同数据库的行为可能完全不同。这不是配置问题，而是 SQL 标准实现差异。
- PostgreSQL：完全支持 CHECK，且支持在 CHECK 中引用其他字段（如
models.Q(end_date__gt=models.F('start_date'))），也支持函数如abs() - MySQL：8.0.16+ 才支持 CHECK，且不支持子查询、用户函数、或跨字段比较中的某些表达式；
models.F('field')可用，但abs(field)会报错FUNCTION database.abs does not exist - SQLite：Django 会跳过 CHECK 约束（除非你手动开启 PRAGMA enable_load_extension），所以本地开发测试时容易误判约束生效
线上环境务必用与生产一致的数据库做迁移验证，别只靠 SQLite 跑 test。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
