1071错误源于MySQL旧版本对utf8mb4索引长度限制，需同时配置Schema::defaultStringLength(191)、database.php中engine设为InnoDB ROW_FORMAT=DYNAMIC、charset/collation设为utf8mb4及对应数据库字符集。
执行 php artisan admin:install 报错 1071：Specified key was too long
这是 MySQL 旧版本（5.7.7 以下，尤其是 5.6 或更低）在启用 utf8mb4 字符集时的典型限制问题。Laravel 5.4+ 默认用 utf8mb4，而 email、name 等字段建唯一索引时，按默认长度 255 计算会超出 MySQL 的最大索引键长（1000 bytes）。错误具体出现在类似这句 SQL 上：alter table `users` add unique `users_email_unique`(`email`)。
为什么 Schema::defaultStringLength(191) 能解决
因为 utf8mb4 下每个字符最多占 4 字节，191 × 4 = 764，小于 1000；同时还能兼容绝大多数邮箱（Gmail 最长支持 254 字符，但索引只取前 191 就足够保证唯一性），且不破坏 Laravel 自动迁移逻辑。
- 必须在
AppServiceProvider::boot()中调用，不能放在register() - 要提前引入：
use Illuminate\Support\Facades\Schema; - 该设置仅影响后续新建的迁移，对已执行过的迁移无效（需先
php artisan migrate:rollback再重试） - 如果项目已存在
users表且报错卡在add unique，直接删表再重装更省事（开发环境）
配置 database.php 中的 engine 参数
仅改 defaultStringLength 不够稳定，尤其在 MySQL 5.7.5 之前或使用 MyISAM 引擎时。建议同步加固表引擎声明：
- 打开
config/database.php，定位到mysql配置块 - 将
'engine' => null改为：'engine' => 'InnoDB ROW_FORMAT=DYNAMIC' -
ROW_FORMAT=DYNAMIC是关键——它允许InnoDB存储更长的索引前缀（配合innodb_large_prefix=ON，MySQL 5.6.3+ 默认开启） - 不推荐强行升级 MySQL 到 8.0 来绕过问题，很多生产环境仍用 5.7，且升级成本远高于配置调整
别漏掉 config/database.php 里的 charset 和 collation
如果数据库本身是 utf8（非 utf8mb4），即使改了 defaultStringLength，迁移仍可能失败。确认以下两项匹配：
'charset' => 'utf8mb4'-
'collation' => 'utf8mb4_unicode_ci'（或utf8mb4_0900_ai_ci，取决于 MySQL 版本） - 对应数据库和表也要手动设为
utf8mb4：ALTER DATABASE your_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 如果用的是低版本 MySQL（如 5.5.x），
utf8mb4不被支持，那就只能降级 Laravel 字符集——但不推荐，会丢 emoji 和部分生僻字支持
真正容易被忽略的是：这三个点（defaultStringLength、engine、charset/collation）必须同时生效才稳定。单独改一个，上线后某次新增字段或重跑迁移，可能又在凌晨三点弹出这个报错。
