最容易漏的是APP_DEBUG=true未关闭和.env文件混入本地密钥直接上线，二者会导致数据库密码、API密钥等敏感信息明文暴露在错误页面，使应用“等着被黑”。
最容易漏的是 APP_DEBUG=true 还没关，以及 .env 文件里混着本地数据库密码、密钥直接上线。 这两个点不处理，等于把服务器大门钥匙挂在门口——不是“可能被黑”，而是“等着被黑”。
APP_DEBUG=true 没关：谁都能看到你的数据库密码
线上环境一旦开着调试模式，任意一个 404 或 PHP 错误，都会触发 Whoops 错误页，里面明文打印出完整的 $_ENV、$_SERVER、数据库连接串、缓存配置，甚至部分源码片段。
- CVE-2021-3129 就是靠这个页面写入后门的，不需要登录、不依赖漏洞函数，纯配置失误
- 检查命令：
grep -r "APP_DEBUG=true" /var/www/your-app/.env，必须是false - 改完别忘了清空缓存：
php artisan config:clear（否则config:cache会缓存旧值） - 如果用 CI/CD 部署，
.env必须由运维侧注入，不能随代码打包
APP_KEY 没重生成：Session 和 Cookie 全部可伪造
新项目克隆后直接跑 composer install，APP_KEY 还是 .env.example 里的默认值或上个项目残留的。这会导致：
- 攻击者可解密所有 Session 数据（含用户登录态、CSRF token）
- 结合反序列化利用（如 CVE-2019-9081），能直接 RCE
- 执行命令：
php artisan key:generate—— 必须在.env写入后、首次启动前运行 - 验证是否生效：
php artisan tinker→echo config('app.key');，确认不是base64:开头的固定字符串
config:cache 和 route:cache 没跑：性能差还暴露路径
没缓存配置和路由，每次请求都要重新加载全部 PHP 配置文件、解析全部路由定义，不仅慢，还会让 APP_DEBUG=false 失效一部分防护能力。
-
config:cache必须在.env确认无误后执行，否则缓存了错误 DB_HOST 会导致全站 500 -
route:cache只对静态路由有效，含闭包路由、动态域名绑定的项目禁用 - 常见报错：
Route cache not found是因为没先跑route:clear；Class not found是因缓存了未 autoload 的类路径 - 执行顺序建议：
config:clear→ 改.env→key:generate→config:cache→route:cache（如适用）
最常被跳过的其实是「部署后验证」：改完 .env、跑完缓存命令，立刻 curl 一个不存在路由，看返回是不是 404 页面而不是 Whoops；再查日志：tail -f storage/logs/laravel.log，确认没有 APP_DEBUG 相关警告。这些动作花不了两分钟，但能拦下 90% 的低级上线事故。
