我刚入行那会儿，第一次接触 Laravel 的数据库配置，实在被 .env 文件搞懵了。明明项目里有个 database.php 文件，为什么还要单独弄个 .env？后来踩了几个坑才明白，这玩意儿的设计挺讲究的。 .env 文件就像个秘密小本本，专门记数据库密码、服务器地址这些敏感信息，关键是还能根据不同环境随意切换。比如开发环境用本地 MySQL，线上用 RDS，只要改一下 .env 里的 DBHOST，就不需要动代码。而且 .gitignore 默认会把 .env 屏蔽，推代码时密码不会泄露，这比把配置写死在代码里强太多。
不过光知道改 .env 还不够，你得明白 database.php 和 .env 是怎么配合的。database.php 里有个 connections 数组，定义了 mysql、pgsql、sqlite 等连接方式，而 .env 里的 DBCONNECTION 则指定使用哪一种。默认是 mysql，但如果想玩轻量的 sqlite，也可以改成 sqlite，甚至还能混用——比如主库用 MySQL，缓存用 Redis。我见过最“骚”的操作是把 .env 里的 DBCONNECTION 设成 pgsql，结果连的却是 MySQL，直接闹笑话。所以配置前最好先弄清楚自己用的是什么数据库，别盲目复制粘贴网上的配置。
说到具体配置，有个坑我至今记忆犹新。一次我把 DBHOST 写成 localhost，本地跑得好好的，一上阿里云就报连接超时。查了半天才发现，localhost 和 127.0.0.1 在 Unix 系统里走的套接字不一样，云服务器上必须使用具体 IP。还有 DBPORT，MySQL 默认是 3306，但如果装的是 MariaDB 或者改了端口，就得手动修改。更坑的是 DBDATABASE 和 DBUSERNAME，我手抖把数据库名写成 “mydb”，用户名写成 “root”，密码虽对，却连不上——因为数据库根本没创建。所以配置前先登录数据库确认一下，别想当然。
读写分离的配置也挺有意思。你可以在 database.php 的 mysql 连接里加上 read 和 write 两个数组，分别指定不同的主机。比如写库用主服务器，读库用从服务器，这样能应对高并发。我有个朋友做电商项目，双十一流量暴涨，就是靠这招撑过去的。不过要注意，Laravel 默认的读写分离并不会强制走从库，而是根据查询语句智能分配。比如 Model::find() 可能走读库，但 Model::where()->update() 必然走写库。如果强制所有查询都走写库，读写分离的意义就失效了。
连接池和持久连接也是容易忽略的点。Laravel 默认不开启持久连接，每次请求都会新建数据库连接，频繁创建销毁确实会浪费资源。但如果打开持久连接，又要防止连接泄漏。我之前接手过一个老项目，生产环境开了持久连接，结果运行几天后 MySQL 连接数飙到几千，直接卡死。后来发现是某个控制器里用了 DB::connection() 却没有及时释放，导致连接堆积。所以建议小项目不要开持久连接，大项目可以考虑使用连接池组件（如 Swoole 或 RoadRunner）来提升稳定性。
缓存配置这块也和数据库挂钩。Laravel 支持把查询结果缓存到 Redis 或 Memcached，但很多人只配了缓存驱动，忘了设置缓存前缀。想象一下，线上和本地共用同一台 Redis，两个项目的缓存 key 冲突，数据就会乱成一团。因此一定要在 .env 里加个 CACHEPREFIX，例如 “myappcache”。更专业的做法是给不同环境使用不同的 Redis 数据库编号，开发用 1，测试用 2，生产用 3，这样可以彻底隔离。
说到迁移配置。Laravel 的 migrations 表默认存在指定的数据库里，但如果有多数据库连接，迁移文件该怎么跑就是个问题。我见过一个团队，开发时本地用 SQLite，线上用 MySQL，结果迁移文件里用了 MySQL 特有的函数，本地直接报错。解决方案是写迁移时尽量使用数据库无关的语法，或者使用 Schema Builder 的方法。还有一个实用技巧：在 database.php 里配置多个连接后，在迁移文件的 up 方法里使用 指定连接，这样同一个迁移文件就能适配不同数据库，省心不少。
写到这里，我突然觉得 Laravel 的数据库配置就像乐高积木，看似复杂，但每个零件都有它的用处。从最基本的 .env 变量到读写分离，从持久连接到缓存前缀，每一步配置都藏着前人踩过的坑。你不需要一次全部弄懂，但每遇到一个问题就去查文档、动手实验，慢慢就能摸清门道。毕竟，配置这东西，纸上谈兵没有意义，得真刀真枪地干过才知道。下次改配置时，不妨多问自己一句：这个参数会影响什么？连接性能？安全性？还是可维护性？想清楚了再改，远比盲目尝试靠谱。
