cache_prefix只影响缓存键，与数据库迁移无关；真正控制迁移表名前缀的是db_table_prefix环境变量，需在迁移文件中手动拼接使用，且修改后须回滚重跑才生效。
为什么CACHE_PREFIX在迁移中完全没起作用
因为CACHE_PREFIX只影响缓存键（如 Redis、File 缓存），和数据库迁移、表名、字段定义毫无关系。有人误以为改了这个就能让migrations表或生成的表带前缀，结果执行php artisan migrate后所有表还是裸名——这不是配置漏了，是根本用错了地方。
真正控制迁移表名前缀的是DB_TABLE_PREFIX环境变量
Laravel 原生不支持全局表前缀，但可以通过DB_TABLE_PREFIX配合手动注入实现。它不会自动加到每个Schema::create()里，但能被你主动读取并拼接使用：
-
DB_TABLE_PREFIX=app_写进.env，然后在迁移文件中显式调用：Schema::create(env('DB_TABLE_PREFIX', '').'users', function (Blueprint $table) { ... }); - 更稳妥的做法是封装一个辅助函数，比如在
database/migrations/_helpers.php里定义prefixed_table($name)，避免每处都写env() - 注意：不能在
config/database.php里直接用env('DB_TABLE_PREFIX')去改'prefix'项——Laravel 的数据库连接初始化早于.env加载完成，此处env()会返回null，导致连接失败
php artisan migrate时表名已固定，改.env无效的典型场景
迁移一旦执行成功，表名就写死在migrations表记录里了。此时再改DB_TABLE_PREFIX，只会让后续新迁移用上新前缀，旧表不会重命名，也不会自动加前缀。
- 已运行的迁移文件（如
2024_01_01_000000_create_users_table.php）里的表名是硬编码的，改.env对它零影响 - 想统一加前缀？必须回滚（
php artisan migrate:rollback --step=1）、修改迁移代码、再重跑；或者手动RENAME TABLE并更新migrations表中的batch和migration字段 - 生产环境严禁直接改
migrations表，应走标准down()+up()流程，否则migrate:status会失真
容易被忽略的兼容性雷区：MySQL 严格模式与前缀长度
如果前缀太长（比如DB_TABLE_PREFIX=prod_v2_legacy_app_），加上原表名后总长度超过 MySQL 表名限制（64 字符），php artisan migrate会直接报错SQLSTATE[42000]，且错误信息不提示是长度问题。
- 检查方式：
SELECT LENGTH('prod_v2_legacy_app_users');，确保 ≤ 64 - MySQL 5.7+ 默认启用
innodb_large_prefix，但它管的是索引长度，不是表名；表名长度限制由服务端硬编码决定，无法通过配置放宽 - 别依赖
str_limit()或substr()截断前缀——语义混乱，后期维护成本爆炸
