.env 配置不能直接暴露给前端，因为硬编码到 HTML 或 JS 中会导致敏感信息（如 API_KEY）明文泄露；应仅通过 config() 传递非敏感配置，并严格白名单过滤。
为什么 .env 里的配置不能直接暴露给前端
因为 Laravel 的 .env 文件在运行时被加载进 PHP 环境变量，但这些变量默认不会自动注入到前端可访问的 JS 或 HTML 中。强行用 json_encode(env('API_KEY')) 塞进模板，等于把密钥明文写进 HTML 源码——只要打开开发者工具就能看到。
- 真正需要“隐藏”的不是 Laravel 后端读取配置的过程，而是防止敏感值泄漏到客户端
-
APP_DEBUG=true时，错误页面可能意外打印.env内容，必须关掉 - 部署时若用
php artisan config:cache，.env只在缓存生成阶段读一次，之后修改.env不生效，容易误以为改了就立刻起作用
哪些配置该放进 config/ 而不是 .env
.env 只放真正随环境变化、且不能硬编码的值；其他所有带逻辑、有默认行为、需类型校验或会被多次调用的配置，都应该落到 config/ 文件里。
- 比如数据库连接参数（
DB_HOST、DB_PORT）放.env；但分页数量paginate.per_page应该定义在config/app.php或自建config/pagination.php中 -
config/services.php是专门收口第三方服务配置的地方，github.client_id这类字段写这里，再通过config('services.github.client_id')调用，比满世界写env('GITHUB_CLIENT_ID')更安全、更易测 - 不要在
config/文件里直接调用env()做条件判断，例如'timeout' => env('API_TIMEOUT', 5) * 1000—— 缓存配置后，env()返回 null，乘法会报错
config:clear 和 config:cache 到底清什么、缓什么
config:cache 把所有 config/ 下的 PHP 文件合并编译成一个静态数组文件 bootstrap/cache/config.php，大幅提升运行时读取速度；config:clear 就是删掉这个文件。
- 开发时频繁改配置，别开
config:cache，否则每次改完都要手动php artisan config:clear，否则看不到效果 - 上线前必须跑
config:cache，否则每次请求都重新 require 所有 config 文件，IO 开销明显 - 如果用了
env()动态拼接路径或开关，例如'log_path' => storage_path(env('LOG_SUBPATH', 'logs') . '/laravel.log')，缓存后env()失效，路径会变成storage/logs//laravel.log—— 这种逻辑必须移到AppServiceProvider的boot()里做
如何安全地把非敏感配置传给前端
只传前端真正需要的、不涉及权限和密钥的配置，比如应用名称、当前语言、资源 CDN 地址。用 config() 读取，再通过 Blade 的 @props 或内联 JSON 注入。
- 在
config/app.php加一项：'frontend' => ['app_name' => env('APP_NAME', 'MyApp'), 'locale' => app()->getLocale()] - 在主模板里写：
<script>window.Laravel = @json(config('app.frontend'));</script> - 禁止在
config()里引用任何以SECRET、KEY、PASS结尾的.env变量，IDE 搜索env.*KEY能快速扫一遍风险点 - 如果项目用了 Inertia 或 Vue Router，注意 SSR 渲染时
window不存在，这类注入要加typeof window !== 'undefined'守卫
Laravel 配置的“隐藏”本质不是加密或混淆，而是控制作用域和传播路径。最常被忽略的是：缓存配置后 env() 不再可用，以及前端注入时没做白名单过滤——这两处一出问题，轻则功能异常，重则泄露凭证。
