WITH CHECK OPTION 是唯一能限制通过视图插入不合规数据的原生机制，仅在 INSERT/UPDATE 时强制新行满足视图 WHERE 条件并报错拦截，不生效于 DELETE、SELECT 或直接操作基表，且必须建视图时声明、仅对可更新视图有效。
WITH CHECK OPTION 能阻止违反视图定义条件的 INSERT/UPDATE 操作，但它只检查 DML 语句执行后的最终行状态，不校验中间过程；没加它，用户可能悄无声息地插入不符合视图逻辑的数据。
为什么 INSERT INTO 视图后查不到新数据？
这是最典型的误用信号：你对一个带过滤条件的视图执行了 INSERT，语句成功返回，但紧接着 SELECT * 却查不到刚插的那条——说明新行不满足视图的 WHERE 条件，而视图又没加 WITH CHECK OPTION，数据库允许“插进去再丢掉”。
- 视图定义如：
CREATE VIEW active_users AS SELECT * FROM users WHERE status = 'active' - 执行
INSERT INTO active_users (id, name, status) VALUES (100, 'Alice', 'inactive')—— 若无WITH CHECK OPTION，该语句通常成功（取决于 DBMS，默认不校验） - 但新行
status = 'inactive'不在视图结果集中，所以后续SELECT看不见它
WITH CHECK OPTION 和 CASCADED / LOCAL 的区别
两者都启用行级约束，但作用范围不同：前者递归检查所有依赖视图的条件，后者只检查当前视图的 WHERE 子句。
-
CASCADED（默认行为）：如果视图 A 基于视图 B，而 B 又有WITH CHECK OPTION，那么向 A 插入数据时，会同时校验 A 和 B 的过滤条件 -
LOCAL：只校验当前视图的条件，忽略底层视图的约束。例如：CREATE VIEW v1 AS SELECT * FROM base WHERE x > 0; CREATE VIEW v2 AS SELECT * FROM v1 WHERE y → 向 <code>v2插入时，只强制y ，不强制 <code>x > 0 - PostgreSQL 默认为
LOCAL，MySQL 和 SQL Server 默认为CASCADED，行为不一致，建视图时必须显式声明
哪些操作会被 WITH CHECK OPTION 拦住？
它只在语句执行完成后做一次快照校验，因此以下情况会被拒绝：
- INSERT 新行不满足视图
WHERE条件（如向WHERE age >= 18的视图插age = 16） - UPDATE 修改后导致行不再属于视图结果集（如把
status = 'active'改成'archived'） - UPDATE 同时修改多个字段，只要最终状态不满足条件，就失败（不关心哪一列触发）
- 注意：
DELETE不受WITH CHECK OPTION影响——它本来就不需要满足“可见”，删的是基表数据
常见陷阱与绕过风险
它不是安全围栏，而是“事后审查”，很多边界情况容易被忽略：
- NULL 值参与比较时可能意外通过校验（如
WHERE col = 'A'，插入col = NULL会导致NULL = 'A'为UNKNOWN，某些 DBMS 视为不违反条件） - 函数或表达式字段（如
WHERE YEAR(created_at) = 2024）在校验时重新计算，但如果created_at是TIMESTAMP且含时分秒，插入'2024-01-01 23:59:59'可能因时区或精度被截断而失效 - 没有主键或唯一约束的视图，
WITH CHECK OPTION无法防止重复插入相同逻辑行（它不管重复，只管单行是否符合条件） - 权限上，用户仍可绕过视图直接写基表——
WITH CHECK OPTION不替代行级安全策略（如 PostgreSQL 的ROW SECURITY POLICY）
真正起作用的前提是：所有数据变更都走这个视图，且你清楚知道每种 DBMS 对空值、类型隐式转换、时间函数的处理差异。
