Laravel 5.5 部署上线核心卡点是 APP_KEY、.env 加载时机、Web 入口指向及 AES-128-CBC 兼容性；万网等虚拟主机不支持 AES-256-CBC，须同步修改 config/app.php 的 cipher 和 APP_KEY 长度，并严格按先配 .env 再运行 key:generate 的顺序操作。
直接上结论：Laravel 5.5 部署上线不是“传完代码就能跑”，核心卡点在 APP_KEY、.env 加载时机、Web 服务器入口指向、以及 PHP 加密 cipher 兼容性——尤其在共享主机（如万网）或旧版 Apache 上，AES-256-CBC 极易报错。
为什么 php artisan key:generate 必须在 .env 配置后执行
很多部署失败源于顺序错误：key:generate 会读取 .env 中的 APP_KEY 值来判断是否已存在；如果先运行该命令再改 .env，生成的密钥会被覆盖，导致 session、加密 cookie 全部失效。
- 必须先
cp .env.example .env，再编辑.env填好数据库、APP_ENV=production、APP_DEBUG=false - 再执行
php artisan key:generate——它会把新密钥写入.env，且仅当APP_KEY为空或长度不对时才生成 - 若用
heroku或 Docker 等环境，APP_KEY应通过环境变量注入，而非写死在.env里
AES-128-CBC 是万网/部分虚拟主机唯一能用的 cipher
万网等老旧共享主机默认不支持 AES-256-CBC（Laravel 5.5 默认），直接报 Unsupported cipher or incorrect key length。不能只改 .env，必须同步改代码层配置。
- 打开
config/app.php，找到'cipher' => 'AES-256-CBC'，改为'cipher' => 'AES-128-CBC' - 对应地，
APP_KEY必须是 16 字符（不是 32），例如base64:1234567890123456（注意 base64 编码后正好 24 字符，但原始字符串为 16 字节） - 别信“改了
.env就行”——Laravel 5.5 的app.php中cipher不走env()，硬编码优先级更高
Web 服务器必须指向 public/ 目录，且重写规则要干净
Nginx/Apache 若指向项目根目录，会暴露 storage/、.env 等敏感路径；而用 .htaccess 做 public 重写时，自带的 trailing slash 301 规则会把 POST 变成 GET，导致 AJAX 失败。
- Nginx 示例配置关键段：
root /var/www/myapp/public;+try_files $uri $uri/ /index.php?$query_string; - Apache 要确保
AllowOverride All且mod_rewrite已启用；public/.htaccess中必须删掉带R=301的 trailing slash 重定向段 - 虚拟主机（如万网）无法改 vhost？那就用根目录
.htaccess把所有请求代理到public/，但注意不能和public/.htaccess冲突
composer install --no-dev --optimize-autoloader 后还缺三步缓存
依赖装完只是开始，没跑缓存命令，每次请求都要动态加载配置、解析路由、编译 Blade，性能直接打五折。
-
php artisan config:cache——合并所有config/*.php，跳过env()运行时解析（所以.env必须提前配好） -
php artisan route:cache——仅适用于非闭包路由的项目（Laravel 5.5 默认满足），大幅减少路由匹配开销 -
php artisan view:cache——把.blade.php预编译为 PHP 文件，避免每次渲染都解析模板
这三步必须在 config:cache 之后执行，否则 route:cache 会因配置未加载而失败；而且一旦运行，后续改 .env 或路由文件，必须手动 php artisan config:clear 等清除缓存才能生效——这点最容易被忽略。
