推荐使用 config() 函数读取配置，它语法简洁、支持点号路径；Config::set() 仅限测试或命令行临时覆盖，不可用于业务逻辑分支，因不跨请求生效。
直接用 config() 函数读取，别碰 Config::get() 以外的静态调用，更别在运行时用 Config::set() 做业务逻辑分支——它只对当前请求生效，下次刷新就丢。
config() 和 Config::get() 有什么区别
两者底层都走同一个配置仓库，但 config() 是推荐的辅助函数，语法更短、支持数组点号路径（如 'database.connections.mysql.host'），且开发体验更一致；Config::get() 是门面调用，功能等价但多一层抽象，无额外优势。
常见错误现象：在控制器里写 Config::set('app.name', 'New Name')，然后期望后续中间件或队列任务能读到——不可能。它不会写入文件，也不跨请求。
- 只在单元测试、Artisan命令调试中临时覆盖配置时才用
Config::set() - 业务代码里一律用
config('key')读，不要尝试写 - 如果真需要“动态改配置”，应改
.env+ 运行php artisan config:clear（开发）或php artisan config:cache（生产）
自定义配置文件怎么命名和加载才有效
Laravel 不会自动加载你随便扔进 config/ 目录的 PHP 文件，必须满足两个硬性条件：文件名全小写+下划线分隔，且末尾必须 return 一个纯数组。
使用场景：比如加微信支付配置，建 config/payment.php，内容如下：
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
<?php
return [
'wechat' => [
'app_id' => env('WECHAT_APP_ID'),
'mch_id' => env('WECHAT_MCH_ID'),
'key' => env('WECHAT_KEY'),
],
'alipay' => [
'app_id' => env('ALIPAY_APP_ID'),
],
];
- 文件名不能是
PaymentConfig.php或paymentConfig.php，必须是payment.php - 不能在文件里写
use、new实例、闭包或任何执行逻辑 - 修改后，开发环境可不清理缓存；但生产环境已执行过
config:cache，就必须重新运行才能生效
为什么改了 .env 但 config() 还读不到新值
因为 php artisan config:cache 把所有配置（包括从 .env 解析出的值）编译成一个静态 PHP 数组，存在 bootstrap/cache/config.php 里。之后所有请求绕过 Dotenv 加载流程，.env 变成摆设。
性能影响很明显：缓存后读取快 3–5 倍；代价是失去热更新能力。
- 开发环境建议禁用
config:cache，避免反复清缓存打断节奏 - 每次改
.env后，必须运行php artisan config:clear（不是cache） - 生产部署流程中，应在
.env写入后再执行config:cache，顺序不能反
env() 函数在配置文件里怎么写才安全
env() 只能在 config/*.php 文件中使用，不能在控制器、模型或服务类里调用——Laravel 5.2+ 已禁止运行时读 .env，否则缓存后直接报错或返回 null。
正确写法永远带默认值，并做类型转换：
'debug' => (bool) env('APP_DEBUG', false),
'timeout' => (int) env('API_TIMEOUT', 30),
'log_level' => env('LOG_LEVEL', 'production'),
- 不写默认值（如
env('DB_HOST')）会导致生产环境缺失变量时配置崩溃 - 不做强制类型转换，可能把字符串
'false'当成布尔true - 别在配置文件里写
if (env('APP_ENV') === 'local') { ... }，应改用App::environment('local')
最易被忽略的一点：config:cache 会拒绝包含闭包、对象或非标量值的配置文件——哪怕只是多了一个 new DateTime()，整个缓存都会失败，且错误提示极其模糊。检查自定义配置文件时，先确认它真的只返回数组。
