乱码根源是mysql字符集与laravel迁移不匹配：utf8仅支持3字节，而utf8mb4才支持emoji和生僻字；需同步配置mysql服务端、laravel连接层（含pdo初始化命令）、迁移文件及表结构，并优先启用innodb_large_prefix而非依赖schema::defaultstringlength(191)降级兼容。
乱码不是前端渲染问题，而是 MySQL 字符集配置和 Laravel 迁移默认行为不匹配导致的。核心在于 utf8 和 utf8mb4 的区别 —— Laravel 5.4+ 默认用 utf8mb4，但老版本 MySQL（utf8（实际是 utf8mb3），遇到 emoji 或中文生僻字就会截断、乱码甚至建表失败。
MySQL 必须启用 utf8mb4 支持
先确认你的 MySQL 版本是否达标：
SELECT VERSION();
如果低于 5.5.3，升级是唯一可靠解法。若已达标，需手动修改 MySQL 配置文件（如 /etc/mysql/my.cnf 或 my.ini），在 [mysqld] 和 [client] 段落中加入：
character-set-server = utf8mb4collation-server = utf8mb4_unicode_ciinit_connect = 'SET NAMES utf8mb4'skip-character-set-client-handshake = true
改完重启 MySQL，并用 SHOW VARIABLES LIKE 'character_set%'; 验证是否全部生效为 utf8mb4。
config/database.php 中 mysql 连接必须显式指定
仅改 MySQL 服务端不够，Laravel 连接层也得对齐。打开 config/database.php，找到 mysql 配置块，在 'charset' 和 'collation' 处强制写死：
'charset' => 'utf8mb4''collation' => 'utf8mb4_unicode_ci'-
'prefix' => ''（避免旧 prefix 导致迁移时字段名超长） -
'strict' => true（开启严格模式，提前暴露字符集问题）
注意：不要留空或写成 utf8，哪怕注释里写着“兼容旧版”——laravel-admin 的 migration 脚本依赖 utf8mb4 下的索引长度计算逻辑。
Schema::defaultStringLength(191) 不是万能解，要慎用
很多教程让你在 AppServiceProvider::boot() 里加 Schema::defaultStringLength(191)，这确实能绕过 Specified key was too long 错误，但它只是降级兼容，不是根治乱码。它本质是把所有 VARCHAR(255) 字段的索引长度从 255×4=1020 字节砍到 191×4=764 字节，防止超出 InnoDB 的 767 字节限制。
但副作用明显：
- 搜索时对长字段（如标题、描述）做
WHERE title LIKE '%xxx%'可能无法命中索引 - 后续想加全文索引或唯一约束会更受限
- 一旦你未来升级到支持
innodb_large_prefix的 MySQL 5.7+，这个设置反而成了冗余枷锁
真正该做的是：确保 MySQL 已启用 innodb_file_format = Barracuda 和 innodb_file_per_table = ON，并在 config/database.php 的 mysql 配置里加上：
'engine' => 'InnoDB ROW_FORMAT=DYNAMIC'
这样就不需要靠 defaultStringLength 削减字段能力了。
页面乱码背后往往是数据库存进去就是乱的，而不是模板没设 charset。检查 admin_users 表里的 name 字段内容是否本身就是问号或方块——如果是，说明问题出在入库环节，上面三步必须全走通；如果入库正常但页面显示异常，再查 Blade 模板里有没有漏掉 <meta charset="utf-8"> 或 Nginx/Apache 是否返回了错误的 Content-Type 头。
