TP8.0不内置蓝绿发布能力，需通过Nginx upstream切换流量并确保代码、配置、运行时、Session及数据库迁移独立隔离与向前兼容。
TP8.0 本身不内置蓝绿发布能力，也不直接管理线上环境切换。你遇到“改错无法回滚”，问题不在框架，而在部署流程没解耦——代码版本（Git）和运行环境（蓝/绿）被混在一起操作了。
Git 提交记录 ≠ 线上可回滚状态
很多人以为 git revert 或 git reset --hard 能立刻让线上服务回到旧版，这是错觉。Git 只管代码快照，不控制：
- 当前哪个 commit 正在被 Nginx 或容器拉起
- 数据库 schema 是否兼容旧版应用逻辑
- Session、缓存、定时任务等状态是否跨版本可用
比如你用 git checkout v2.1.0 重新打包部署，但数据库已执行了 v2.2.0 的迁移脚本（删字段、改类型），TP8.0 启动时就会报 SQLSTATE[42S22]: Column not found 或 Call to undefined method —— 这不是代码没回滚，是环境不匹配。
Nginx upstream 切换才是蓝绿核心动作
蓝绿的关键不是“多一份代码”，而是让两套独立的 TP8.0 实例（不同端口、不同目录、不同环境变量）同时存活，靠 Nginx 的 upstream 指向控制流量入口：
upstream app_blue {
server 127.0.0.1:8001;
}
upstream app_green {
server 127.0.0.1:8002;
}
<p>server {
listen 80;
location / {
proxy_pass <a href="https://www.php.cn/link/dd9e6330d5cee8784b5c43ea3192d499">https://www.php.cn/link/dd9e6330d5cee8784b5c43ea3192d499</a>; # 默认走 blue
}
}</p>
发布新版本时：
- 在 /var/www/app_green 拉取新 Git tag，composer install --no-dev，检查 env 配置
- 启动 PHP-FPM pool 指向该目录（端口 8002）
- 修改 Nginx 配置，把 proxy_pass 指向 app_green，然后 nginx -s reload
- 观察日志和监控，异常就改回 app_blue，reload 即可秒级回滚
TP8.0 需要手动适配的三个点
TP8.0 默认假设单实例运行，蓝绿下容易踩坑：
智能分析 Git 仓库或普通链接，自动识别内容类型并执行相应处理流程。 支持四种类型：1) OpenClaw Skills 项目（风险检测与收藏）2) 论文/文档项目（加入 dashifu——wiki 待处理队列）3) 功能项目（评估 OpenClaw 学习可行性）4) 普通网页/文章（加入 dashifu——w...
-
配置隔离：不要共用
.env文件。蓝/绿目录各自维护独立.env，尤其APP_ENV、DB_HOST、REDIS_HOST必须指向对应环境 -
Runtime 目录分离：修改
config/app.php中的runtime_path，例如：runtime_path => '/var/www/app_blue/runtime/'，避免两个实例写冲突 -
Session 存储必须外置：禁用
file驱动，改用 Redis 或数据库。否则切流后用户登录态丢失或复用旧 session 导致权限错乱
数据库迁移不能跟着蓝绿走
这是最常被忽略的致命点。蓝绿要求新旧版本共存，但 php artisan migrate 是破坏性操作：
- 如果只在 green 执行 migration，blue 实例读不到新字段 → 报错 - 如果在 blue 也执行，green 回滚后字段还在，但 blue 代码没适配 → 还是报错
正确做法只有两个：
- 所有 DB 变更必须向前兼容：加字段不删字段、加索引不改类型、用
json字段兜底结构变化 - 真正不可逆的操作（如删表），必须安排在蓝绿切换完成、确认 green 稳定后，再单独执行，并确保 blue 实例已下线
别指望 TP8.0 自动帮你协调数据库和代码版本——它连 deployment 都不参与，这事得由运维脚本或 CI 流水线显式控制。
