laravel部署安全的核心是环境隔离、运行时控制和访问权限三重防线：.env须禁入git、配置统一用env()读取、生产禁用app_debug、config缓存后需屏蔽bootstrap/cache目录、前端严禁暴露密钥或明文id。
部署 Laravel 时，“隐藏”不是把文件藏起来，而是切断敏感信息从服务器流向外部的每一条路径——核心在环境隔离、运行时控制和访问权限三重防线。APP_KEY 泄露等于交出全量解密钥匙，.env 提交到 Git 是最常见也最致命的起点。
环境变量必须彻底隔离
.env 文件是敏感配置的唯一入口，但也是最大风险点：
- 务必加入 .gitignore，且检查历史提交是否已误传过 APP_KEY、DB_PASSWORD、MAIL_PASSWORD 等字段
- 所有配置读取统一用
env('DB_HOST')，禁止在 config/ 文件里直接写死值或使用$_ENV/getenv() - CI/CD 流水线中，应通过安全变量注入环境值，而非复制 .env 文件
- 本地开发可设
APP_DEBUG=true，但生产环境必须为false，否则错误页可能泄露 .env 全文
配置缓存既要提速，更要防泄密
启用 php artisan config:cache 后，所有配置被编译进 bootstrap/cache/config.php ——这个文件一旦被 Web 服务器误配为可下载，就等于打包送密钥。
- 每次修改 .env 后，开发环境执行
php artisan config:clear；上线前必须跑config:cache - Nginx 配置中加：
location ^~ /bootstrap/cache { return 403; }；Apache 加：<directory> Deny from all </directory> - 避免在 config/ 中用
env()做动态计算，例如'timeout' => env('API_TIMEOUT', 5) * 1000—— 缓存后env()返回 null，导致报错；这类逻辑应移入AppServiceProvider::boot()
前端绝不接触任何密钥或原始 ID
把 {{ config('app.key') }} 或 {{ $user->id }} 写进 Blade 模板，等于主动外泄。真正安全的“隐藏”，是让前端根本拿不到可推测的明文。
- 禁用 Blade 中调试式输出密钥，不写
{{ config('app.key') }}，也不用json_encode(env('API_KEY'))注入 JS - 需传给前端的仅限非敏感项：应用名、语言、CDN 地址等，统一走
config()白名单过滤后注入 - 表单 hidden 字段、URL 参数、分页游标等场景，一律用
Crypt::encryptString($order->id)替代明文 ID；解密端必须捕获DecryptException，不能只 catch Exception
模型字段隐藏 ≠ 配置隐藏，别混用
$hidden = ['password'] 只影响模型转数组或 JSON 时的输出，对日志记录、中间件、配置加载完全无效。有人把 APP_DEBUG 塞进模型属性再设 $hidden，纯属无效操作。
-
$hidden和$casts['secret'] = 'encrypted'是模型层行为，解决的是数据展示问题 - 配置安全靠的是环境分离、缓存管控、运行时加密、路径权限限制 —— 它们属于框架部署层，不可替代
- 第三方服务配置（如 GitHub client_id）应统一收口到
config/services.php，再通过config('services.github.client_id')调用，比满世界写env('GITHUB_CLIENT_ID')更易维护、更安全
