phalcon模型验证必须与数据库约束同步，即not null对应presenceof、unique对应uniqueness，确保save()失败时getmessages()能准确归因；禁止手动判断绕过validate()，所有验证须走统一流程并分类处理错误消息。
Phalcon 模型验证与数据库约束同步，是为了避免业务逻辑层校验通过但数据库写入失败，或数据库已设约束却在模型层重复、遗漏、冲突校验，导致数据不一致、错误掩盖、安全边界失效。
确认数据库约束是否存在冗余或缺失
登录 MySQL 执行：SHOW CREATE TABLE `users`;，重点检查 NOT NULL、UNIQUE、CHECK（MySQL 8.0.16+）、外键约束是否与业务语义匹配。
若字段定义为 email VARCHAR(255) NOT NULL UNIQUE，但模型中未对 email 做 PresenceOf + Uniqueness 验证，则插入空值或重复邮箱时，数据库会报错但模型层无法捕获具体原因——这会暴露底层错误信息给前端，也绕过业务规则拦截。
【必须同步：数据库的 NOT NULL 和模型的 PresenceOf 必须一一对应】
模型 validation() 方法中复用数据库约束语义
方法一：用内置验证器映射数据库约束
在 Users.php 模型中，将 validation() 方法写成：
$this->validate(new PresenceOf(['field' => 'email', 'message' => '邮箱不能为空']));
$this->validate(new Uniqueness(['field' => 'email', 'message' => '该邮箱已被注册']));
$this->validate(new Email(['field' => 'email', 'message' => '邮箱格式不正确']));
这三行分别对应数据库的 NOT NULL、UNIQUE、业务层格式要求；其中前两项是数据库约束的语义复现，不是替代——它们必须存在，否则 save() 失败时 getMessages() 返回的错误将不可控。
禁止在模型中绕过数据库约束做“假验证”
第一步：检查是否有类似以下代码
if (empty($this->email)) { return false; }
第二步：确认该判断是否独立于 PresenceOf 验证器调用
第三步：如果存在且未调用 $this->validate()，则删除该手动判断——它无法触发 getMessages() 统一收集，且容易漏掉空格、零宽字符等边界情况，而 PresenceOf 内置了 trim 和 strict 判断。
第四步：确保所有字段级验证最终都走 $this->validate() 流程，否则 validationHasFailed() 不生效，save() 仍会直连数据库触发原生错误。
处理 save() 返回 false 后的错误归因
执行 $user->save() 后，不要只用 echo $user->getMessages()[0]->getMessage(); 粗暴输出。
应遍历全部消息并按类型分类：
foreach ($user->getMessages() as $message) {
if ($message->getType() === 'PresenceOf') { /* 触发前端必填提示 */ }
elseif ($message->getType() === 'Uniqueness') { /* 触发重试或建议修改 */ }
else { /* 记录日志，不返回给用户 */ }
}
这样可区分模型层验证失败与数据库约束冲突，避免把 Duplicate entry 'xxx' for key 'email' 这类原始报错直接暴露。
