Doctrine 的 schema:update --dump-sql 仍显示已删除迁移文件中的 ALTER 语句，根本原因在于实体类（Entity）的映射定义（如 @ORM\Column(nullable=false)）与数据库实际结构不一致，而非迁移文件本身——删除迁移 PHP 文件无法覆盖实体元数据对 Schema 的权威声明。
doctrine 的 `schema:update --dump-sql` 仍显示已删除迁移文件中的 alter 语句，根本原因在于实体类（entity）的映射定义（如 `@orm\column(nullable=false)`）与数据库实际结构不一致，而非迁移文件本身——删除迁移 php 文件无法覆盖实体元数据对 schema 的权威声明。
在 Symfony + Doctrine 项目中，doctrine:schema:update 命令完全基于实体类的注解、属性或 YAML/XML 映射配置来推导目标数据库结构，而非依赖已执行或已删除的迁移文件。这意味着：即使你已手动删除 Version20220601122421.php 迁移文件，只要 Category 实体中仍声明 status 字段为非空（例如 @Column(type="string", nullable=false)），Doctrine 就会认为该列本应为 NOT NULL，而当前数据库若仍允许 NULL，则 --dump-sql 必然输出 ALTER TABLE categories ALTER status SET NOT NULL。
✅ 正确解决步骤如下：
-
检查并同步实体映射
定位 Category 实体类（通常位于 src/Entity/Category.php），确认 status 属性的映射是否与预期一致：// src/Entity/Category.php use Doctrine\ORM\Mapping as ORM; #[ORM\Entity] class Category { // ... #[ORM\Column(type: 'string', nullable: false)] // ← 关键：nullable=false 表示必须非空 private ?string $status = null; }若你不希望该字段强制非空，请修改为 nullable: true：
#[ORM\Column(type: 'string', nullable: true)] private ?string $status = null;
-
验证数据库实际状态
手动查询数据库，确认 categories.status 列当前是否允许 NULL：-- PostgreSQL SELECT is_nullable FROM information_schema.columns WHERE table_name = 'categories' AND column_name = 'status';
-- MySQL SHOW COLUMNS FROM categories LIKE 'status';
若结果为 YES（即允许 NULL），但实体声明 nullable=false，则 schema diff 必然触发 SET NOT NULL。
-
同步后重新生成/验证
修改实体后，再次运行：bin/console doctrine:schema:update --dump-sql
若输出为空，说明映射与数据库已一致；若仍有变更，可安全执行：
bin/console doctrine:schema:update --force
⚠️ 重要提醒：
- ❌ 不要仅靠删除迁移文件来“撤销”数据库变更——迁移文件仅是执行记录，Schema 真实来源是实体映射 + 数据库现状。
- ✅ 生产环境强烈建议始终使用 doctrine:migrations 管理变更（如 migrate:rollback），而非 schema:update，以保障版本可控与回滚能力。
- ? 可通过 bin/console doctrine:mapping:info 快速检查所有实体映射状态，辅助诊断不一致问题。
总结：迁移文件是“历史快照”，而实体映射才是 Doctrine Schema 的“权威蓝图”。修复残留 SQL 的本质，是让实体定义（what should be）与数据库现状（what is）达成一致。
