当删除迁移 PHP 文件后，doctrine:schema:update --dump-sql 仍输出旧的 ALTER TABLE 语句，根本原因在于 Doctrine 并非依赖迁移文件判断数据库结构，而是依据实体类（Entity）的映射配置——需同步修正实体字段的 nullable 约束。
当删除迁移 php 文件后，`doctrine:schema:update --dump-sql` 仍输出旧的 `alter table` 语句，根本原因在于 doctrine 并非依赖迁移文件判断数据库结构，而是依据实体类（entity）的映射配置——需同步修正实体字段的 `nullable` 约束。
在 Symfony + Doctrine 项目中，doctrine:schema:update 命令完全忽略已删除的迁移文件，它仅基于当前 PHP 实体类（如 Category）的 Doctrine 映射元数据（Annotation、Attribute 或 YAML）来推导“期望的数据库结构”，再与实际数据库结构比对生成差异 SQL。
因此，你看到的残留语句：
ALTER TABLE categories ALTER status SET NOT NULL
说明：实体类中 status 字段当前被声明为 nullable=false（或未显式设为 true），但数据库表中该列仍允许 NULL —— Doctrine 检测到不一致，便试图“修复”。
✅ 正确解决步骤如下：
- 定位 Category 实体类（例如 src/Entity/Category.php）；
- 检查 status 字段的映射定义，重点关注 @ORM\Column 中的 nullable 属性：
// ✅ 正确：若数据库中 status 已允许 NULL，且你希望保持此状态 #[ORM\Column(type: 'string', nullable: true)] // 或 @ORM\Column(type="string", nullable=true) private ?string $status = null; // ❌ 错误：若数据库实际为 NULLABLE，但此处写成 nullable=false（默认值） #[ORM\Column(type: 'string')] // 等价于 nullable=false → Doctrine 会强制执行 SET NOT NULL private ?string $status = null;
-
根据数据库真实状态统一配置：
- 若数据库 categories.status 列允许 NULL（即你已手动回滚或未执行过该迁移），则实体中必须显式设置 nullable: true；
- 若你确实需要 NOT NULL 约束，应保留迁移并确保其已成功执行（用 doctrine:migrations:status 验证），而非删除文件后强行绕过。
-
验证修复效果：
修改实体后，再次运行：bin/console doctrine:schema:update --dump-sql
若输出为空（Nothing to update - your database is already in sync with the current entity metadata.），说明映射与数据库达成一致。
⚠️ 重要提醒：
- 不要依赖 schema:update 在生产环境同步结构——它不生成可追溯的迁移版本，易引发不可逆错误；
- 删除迁移文件前，务必确认该变更已通过 doctrine:migrations:migrate 完整执行且无需回滚；
- 推荐始终使用 doctrine:migrations:diff 生成迁移，而非手动编写 SQL，以保障元数据与迁移逻辑严格一致。
总结：Doctrine 的 schema 更新机制是“元数据驱动”，迁移文件仅是变更记录载体。删文件 ≠ 删约束，真正决定结构的是实体映射。保持二者同步，才是消除残留 SQL 的唯一可靠方式。
