绝大多数场景下不需要手写维护模式中间件，应优先使用 laravel 自带的 php artisan down 命令；仅当需动态倒计时或对接运维系统通知时才考虑自定义。
维护模式中间件该不该自己写
Laravel 自带 php artisan down 命令和配套的维护模式机制，**绝大多数场景下不需要手写中间件**。它已覆盖路由拦截、缓存响应、允许白名单 IP 绕过、支持自定义模板等核心需求。自己写中间件容易重复造轮子，还可能绕过框架对 APP_DEBUG、down 状态的统一判断逻辑。
只有两种情况值得考虑自定义：需要在维护页里动态显示倒计时（比如“预计 14:30 恢复”），或必须对接内部运维系统触发通知。否则，优先用官方方案。
如何正确启用 Laravel 内置维护模式
直接运行命令即可，但有几个关键点决定行为是否符合预期：
-
php artisan down默认返回 HTTP 503，页面由resources/views/errors/503.blade.php渲染 —— 如果这个文件不存在，会回退到框架默认页，样式简陋 - 加
--render=xxx可指定 Blade 视图，比如php artisan down --render="maintenance"会渲染resources/views/maintenance.blade.php - 加
--secret="xxx"生成访问密钥，带上?secret=xxx参数可绕过维护页 —— 这比写 IP 白名单更安全，尤其在动态 IP 环境下 - 维护状态写入
storage/framework/down文件，不是环境变量或数据库，所以多机部署时需确保共享存储或同步该文件
维护页里调不到 config() 或 env() 怎么办
维护页是在应用完全启动前渲染的，Laravel 此时尚未加载配置服务，所有 config('app.name')、env('APP_URL') 都会返回 null 或触发错误。这不是 bug，是设计使然。
解决方案很直接：
- 维护页模板里只用硬编码值或 PHP 常量，比如
<?php echo $_ENV['APP_NAME'] ?? 'MyApp'; ?> - 如果必须动态内容，把信息写进
storage/framework/down文件本身（artisan down 支持--message和--retry，它们会被序列化进该文件），然后在视图中用file_get_contents(storage_path('framework/down'))读取并解析 - 避免在维护页里调用任何 Eloquent、Redis、DB 连接 —— 它们根本没初始化
上线后忘记 php artisan up 导致服务持续不可用
这是最常被忽略的操作闭环问题。没有自动恢复机制，一旦部署脚本失败或人工遗漏，站点就一直挂着 503。
建议在部署流程中强制加入检查：
- CI/CD 脚本末尾加
php artisan up || echo "WARNING: up failed, check storage/framework/down" - 监控脚本定期检查
storage/framework/down文件是否存在且未过期（比如超过 2 小时） - 如果用了
--retry=60，浏览器会带Retry-After: 60响应头，但这个头对 SEO 和用户感知几乎无用，别依赖它
维护模式不是开关，是临时状态；它的“临时性”必须靠流程兜底，而不是靠人记性。
