laravel生产环境安全需卡死每个环节：app_env=production与app_debug=false是前提，.env严禁提交，datatables须显式排除敏感字段，storage/cache权限应为755而非777，ai服务需隔离密钥并限制响应流。
生产环境 Laravel 应用一旦暴露敏感配置、权限失控或未过滤输入，5 分钟内就可能被横向渗透。安全不是“加个中间件”就能解决的事，而是每个环节的默认行为都得卡死攻击面。
APP_ENV 和 APP_DEBUG 必须为 production / false
这是所有后续安全措施生效的前提。Laravel 在 APP_DEBUG=true 时会把完整异常堆栈、环境变量、SQL 查询原样输出到浏览器——攻击者连登录都不用，直接触发一个 404 就能拿到数据库密码。
- 检查线上
.env文件：必须含APP_ENV=production和APP_DEBUG=false，缺一不可 - 确认没被 Git 提交过：
git ls-files | grep .env应无输出；若历史中存在，需用git filter-repo彻底清理 - 不要依赖服务器环境变量覆盖：Laravel 优先读
.env，环境变量只在.env缺失时兜底
敏感字段必须从 API 响应和 DataTables 中显式排除
哪怕用了 Eloquent 的 $hidden 属性，DataTables::eloquent() 或手动 select() 仍可能绕过——尤其当查询构造器里写了 ->select('*') 或未限制字段时。
- 在
DataTables配置中强制排除：->exclude(['password', 'remember_token', 'api_token']) - API 控制器返回前做二次校验：
array_diff_key($data, array_flip(['password_hash', 'private_key'])) - 避免在
config/datatables.php中启用'use_wildcards' => true，防止搜索参数注入通配符引发越权匹配
storage/ 和 bootstrap/cache/ 目录权限不能是 777
这两个目录被 Web 进程（如 www-data）写入是必须的，但设成 777 等于给攻击者开了个 shell 入口：他们可上传恶意 PHP 文件、篡改缓存视图、甚至覆盖 bootstrap/cache/config.php 注入后门。
- 正确做法：
chown -R www-data:www-data storage bootstrap/cache（按实际 Web 用户名调整） - 权限设为
755而非777：chmod -R 755 storage bootstrap/cache - 验证是否真能写：
sudo -u www-data touch storage/test_write && rm storage/test_write，失败说明权限或 SELinux 拦截
AI 驱动服务必须隔离密钥与响应流
Laravel 12+ 的 Ai::prompt() 或自定义 LLM 客户端若直接拼接用户输入进提示词（prompt），会触发 prompt 注入；若未限制响应流超时或未熔断，还可能被拖垮整个事件循环。
- 禁用原始
env()调用：配置中所有 AI 密钥必须走config('ai.api_key')，不能在config/ai.php里写env('OPENAI_API_KEY')（缓存后失效且易泄露） - 流式响应必须设超时：
Http::timeout(45)->stream(...)，云厂商 API 推荐 ≤45s，本地 vLLM ≤120s - 敏感上下文不进日志：
Log::info('AI request', ['prompt_length' => strlen($prompt)])，绝不能记录$prompt原文
最常被跳过的其实是「权限验证链」：Gate 检查了菜单，但没检查对应 API 的数据范围；DataTables 过滤了字段，但没校验当前用户是否有权访问该行数据。安全不是 checklist 打完就完，而是每次请求进来，都要问一句：这个值，到底是谁授权它出现的？
