composer回滚不触发迁移，但会破坏迁移上下文，导致迁移命令因类缺失、命名空间变更或结构不兼容而失败；需手动恢复迁移文件并执行rollback而非删记录。
直接说结论：composer require vendor/package:1.2.3 --with-all-dependencies 这类版本回滚操作，本身不触发数据库迁移，但会破坏迁移上下文——尤其当旧版本依赖的迁移类已删除、命名空间变更或数据库结构约束不兼容时，php artisan migrate 或 doctrine:migrations:migrate 极大概率失败。
回滚后迁移命令报 “Class not found” 怎么办
这不是 autoload 没刷新，而是迁移类文件在新版本中存在、在旧版本中已被移除或重命名。Composer 回滚只换代码，不还原数据库状态，也不管 migration 文件是否还“合法”。
-
composer show vendor/package看当前实际装的是哪个版本，确认它是否真包含你要的 migration 类 - 检查
database/migrations/（Laravel）或migrations/（Doctrine）目录下，对应时间戳的文件是否存在；若已被删，就得从 Git 历史里git checkout HEAD~3 -- database/migrations/20230515102233_*.php手动恢复 - 类名必须严格匹配文件名：Laravel 要求
20230515102233_add_profile_table.php里定义class AddProfileTable，少一个字母就扫不到 - 别指望
composer install自动补 migration 文件——它只装包，不复制资源
为什么 composer update 不会自动回退已执行的迁移
迁移工具（Laravel/Doctrine/Phinx）只看 doctrine_migration_versions 表或 migrations 表里的记录，和 Composer 锁定的包版本无关。你回滚到旧版代码，但数据库里那条 20230515102233 的记录还在，迁移命令就跳过它——哪怕旧版代码根本没这个类。
- 后果是：数据库结构比代码“超前”，比如新加的字段在旧版模型里没定义，运行时报
SQLSTATE[42S22]: Column not found - 正确做法不是删表记录，而是显式执行
php artisan migrate:rollback --step=1或doctrine:migrations:execute --down 20230515102233，让迁移工具自己管理状态 - 如果旧版没提供对应的
down()方法（常见于 Laravelmigrate:fresh场景），回滚只能靠手动 SQL 或备份还原
Monorepo 中跨服务回滚对迁移的连锁影响
在统一 database/migrations/ 目录下，一个服务的包版本回滚可能让其他服务的迁移失效——比如 order-service 回滚到 v1.2，但它的 20230601_create_orders_table.php 依赖 user-service v2.0 才引入的 users.uuid 字段，而当前 user-service 是 v1.5，没这个字段。
- 迁移文件名里的服务前缀（如
20230601_order_service_create_orders_table.php）只是逻辑分组，不解决依赖冲突 -
--filter只能筛类名，不能解决外键/字段依赖断裂；Doctrine 的up-to-date检查也只看版本表，不校验实际 schema - 真正要安全回滚，得先用
doctrine:schema:validate或php artisan tinker手动验证关键表结构，再决定是否允许迁移命令执行 - CI 流水线里加这步：回滚后跑
php artisan migrate:status --quiet || exit 1，状态异常就中断部署
最常被忽略的一点：回滚操作本身不改变 .env 或数据库连接配置，但旧版本代码可能读取不到新环境变量（比如 Laravel 9+ 的 config/database.php 里用了 $_ENV['DB_URL']，而旧版只认 DB_HOST），导致迁移连不上库——错误信息还是 “Class not found”，实际是连接失败后 autoloader 报错。
