app_key泄露将导致所有加密数据可被批量解密且session、cookie、队列全部失效或可伪造；.env未忽略进git是最常见危险源头，必须用php artisan key:generate生成32字节强随机密钥并确保无bom、权限600。
APP_KEY 泄露 = 所有加密数据可被批量解密，且 session、cookie、队列全部失效或可伪造；.env 文件未忽略进 Git 是最常见也最危险的泄露源头。
APP_KEY 必须用 php artisan key:generate 生成，不能手写或复制
这个命令会生成一个 32 字节（base64 编码后 44 字符）的强随机密钥，并写入 .env 的 APP_KEY 行。手动填 APP_KEY=abc123 或用 Str::random(32) 拼凑，会导致：
RuntimeException: A key of the proper length must be provided.- Laravel 启动失败，或
Crypt::encrypt()抛出Encrypter初始化异常 - Windows 记事本保存的
.env带 BOM 头，导致密钥开头多出不可见字符
运行前确认在项目根目录，且 vendor/autoload.php 已加载（即已执行过 composer install）。
敏感配置必须存在 .env，不能写进 config/*.php
所有密码、密钥、令牌都该走 env() 函数读取，例如：
return [
'password' => env('DB_PASSWORD', ''),
'secret' => env('STRIPE_SECRET', ''),
];
这样做的关键好处是：
-
.env可被.gitignore排除，避免提交到仓库 - 不同环境（dev/staging/prod）共用同一份代码，只换
.env即可切换配置 -
config:cache命令能安全缓存配置（但注意：缓存后env()不再实时读取.env，所以部署后务必先生成缓存再上线）
别把 APP_KEY 以外的密钥硬编码进 config/app.php —— 那等于把密钥和代码打包分发。
PHP中文网提供Laravel 13.2.0版本下载，Laravel框架 是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。
API 密钥这类需动态管理的敏感值，必须存数据库，不能放 .env
比如客户调用你 API 用的 X-API-Key，如果写死在 .env 里：
- 无法按客户端禁用/轮换
- 无法设置有效期或权限分级
- 密钥泄露后无法“立即吊销”，只能改代码+发版
正确做法是建表 api_keys，字段至少含：api_key（用 hash_hmac('sha256', $raw, config('app.key')) 存哈希）、is_active、expires_at。验证时用：
ApiKey::where('api_key', $key)
->where('is_active', true)
->whereRaw('expires_at > ?', [now()])
->first();
别用 ->firstOrFail()，查不到是常态，应返回 401 而非 500。
Crypt::encryptString() 适合加密数据库字段，但绝不适用于密码
它提供可逆加密，适用于 API 密钥、第三方凭证、用户备注等“需要还原原文”的场景。但要注意：
- 加密结果是 base64 字符串，长度比原文长约 33%，数据库字段类型推荐
TEXT，别用VARCHAR(255) - 必须
try/catchDecryptException，比如 APP_KEY 被重置后，旧数据全无法解密 - 绝不能用来存密码——密码必须用
Hash::make()做单向哈希 - 模型里别写自动加解密访问器，会导致
where()查询失效、JSON 序列化异常、日志误打明文
真正要加密字段时，只在明确业务逻辑中手动调用 Crypt::encryptString($value) 和 Crypt::decryptString($encrypted)，时机可控、行为可测。
最常被跳过的一步：检查 .gitignore 是否真包含 .env，以及生产服务器上的 .env 文件权限是否设为 600。这两处漏掉，前面所有加密措施都形同虚设。
