php artisan key:generate 必须最先执行，否则后续缓存命令会失败；它生成app_key用于解密session、cookie等，且重复运行将使旧会话失效。
php artisan key:generate 必须最先执行，否则后续所有缓存命令都会失败或生成无效配置。
php artisan key:generate 是部署启动点，不是可选项
Laravel 启动时依赖 APP_KEY 解密 session、cookie 和加密字段。没它，config:cache 会报错「The only supported ciphers are AES-128-CBC and AES-256-CBC」，route:cache 也可能因加密失败中断。
- 这个命令只写入
.env文件的APP_KEY行，不改其他配置 - 必须在
composer install --no-dev --optimize-autoloader之后运行（否则artisan可能找不到类） - 如果重复运行，旧 session 和 cookie 全部失效 —— 生产环境切勿手抖多跑一次
php artisan config:cache 要紧接在密钥之后
缓存配置是性能关键动作，但前提是 APP_KEY 已存在且有效。
- 它把所有
config/*.php合并为单个bootstrap/cache/config.php，跳过每次请求的文件加载和解析 - 若
.env里有语法错误（比如漏了引号、用了中文等号），此命令直接报错退出，不会静默忽略 - 不要手动编辑缓存后的
config.php—— 下次再跑config:cache就会被覆盖
php artisan route:cache 和 php artisan view:cache 看场景选
这两个不是必跑项，但一旦启用就得理解限制：
-
route:cache：- 仅支持闭包路由以外的定义方式（即不能在
routes/web.php里写Route::get('/', function () { ... })） - 不兼容动态域名路由（
Route::domain('{tenant}.example.com')）和运行时注册的路由 - 缓存后
php artisan route:list显示的是缓存内容，不是源码
- 仅支持闭包路由以外的定义方式（即不能在
-
view:cache：- 把
.blade.php编译成 PHP 文件，存在storage/framework/views/ - 若你用 CI/CD 每次部署都清空
storage/，那这步意义不大；反之，若storage/持久化，就值得跑 - 修改 Blade 模板后必须重新执行，否则用户看到的是旧编译结果
- 把
php artisan migrate --force 的时机和风险
数据库迁移不该放在缓存命令之前，也不该无条件加 --force。
- 先确保
config:cache成功，否则迁移可能连不上数据库（缓存未生效，读的还是默认配置） -
--force只是绕过「当前是生产环境，确认要运行迁移？」的交互提示，不解决 SQL 冲突或结构不兼容问题 - 更安全的做法是：先在 staging 环境验证迁移脚本，再上线；或拆出
up/down明确步骤，避免误删数据
缓存命令和迁移顺序错了，轻则 500 错误，重则服务不可逆中断 —— 这些不是“跑完就行”的步骤，而是环环相扣的执行链。
