Laravel 8 和 11 在数据库连接故障转移方面没有本质差异——官方核心均不支持主库宕机后自动将写操作切至从库；原生仅支持读操作在 read host 列表中顺序 fallback，写操作（INSERT/UPDATE/事务等）强制走单 write 连接，主库挂即报 Connection refused，DB::failover() 非原生方法。
Laravel 8 和 11 在数据库连接故障转移方面**没有本质差异**——官方核心至今不支持“主库宕机后自动把写操作切到从库”这类跨角色故障转移。所谓“故障转移”，在 Laravel 原生语境中仅指读操作在多个从库间按顺序尝试连接（read host 列表 fallback），而非主库挂了就接管写流量。真正关键的区分点不在版本，而在于：**读写分离是框架原生支持的路由机制；主从故障转移（尤其写库切换）必须靠外部方案补足。**
读写分离：Laravel 原生配置的核心结构
这是所有版本（8/9/10/11）统一要求的基础配置，不满足则读写分离根本不会触发：
- 必须在
config/database.php的同一连接名（如'mysql'）下嵌套'read'和'write'子键，不能新建两个独立连接（如mysql_master和mysql_slave） -
'read'必须是数组，即使只有一个从库也要写成['host' => ['192.168.1.10']]，不能是字符串'host' => '192.168.1.10' -
'write'只能是一个关联数组（如['host' => '192.168.1.5']），不支持数组形式，也不支持多主 - 共用字段（
database、username、password、charset等）必须提至外层，写在read或write内部会被忽略 -
'driver' => 'mysql'必须显式声明在外层，否则连接初始化失败
主从故障转移：原生能力边界与常见误解
Laravel 从不提供“主库不可用时自动降级写操作”的能力。它的“fallback”仅限于读操作层面：
- SELECT、count()、exists() 等只读查询会按
'read' => ['host' => [...]]中的顺序逐个尝试连接，遇到第一个通的就用，这就是唯一的原生 fallback - INSERT、UPDATE、DELETE、事务（
DB::transaction()）、DB::statement()全部强制走write连接，主库挂了直接抛PDOException: Connection refused -
DB::failover()不是 Laravel 原生方法，调用会报BadMethodCallException；相关功能来自第三方包（如laravel-db-failover），需自行集成并承担兼容性风险 - 所谓“从库故障转移”实际是运维层行为（如 Keepalived + VIP、ProxySQL、MySQL Router），Laravel 只负责把读请求发给它配置的 host 列表
sticky 选项：解决主从延迟的关键开关
这个配置直接影响读写一致性体验，不是可有可无的优化项：
- 默认
'sticky' => false：用户刚提交表单，紧接着User::find(1)可能落到尚未同步的从库，查不到最新数据——这是预期行为，不是 bug - 设为
'sticky' => true：当前请求周期内一旦执行过写操作（save()、update()、DB::insert()等），后续所有读查询（包括 Eloquentfind()、get()）都会强制走主库，确保立即读取到刚写入的数据 - 事务内所有查询天然走主库，
sticky对事务无额外影响，但事务结束后若仍需读最新数据，sticky能延续主库路由
版本无关的验证与调试建议
无论用 Laravel 8 还是 11，都应通过实测确认行为是否符合预期：
- 在
AppServiceProvider@boot中启用日志：DB::enableQueryLog() - 执行
User::first()后调用dd(DB::getQueryLog())，检查 SQL 对应的connectionhost 是否为从库地址 - 执行
User::create([...])后再查一次，确认写操作是否命中主库 host - 临时停掉主库 MySQL 服务，再发起一个 SELECT 查询，观察是否按顺序尝试从库列表中的下一个 host（需确保应用未因连接池缓存而卡住）
