正式环境与预发环境对比文档

一、结论

当前服务器已经形成两套后端运行环境。

预发环境不是复用正式数据库，而是复制正式库后使用独立数据库 congcong_staging，并使用独立 MySQL 用户、独立 Redis DB、独立 .venv 和独立 Supervisor 服务。

二、后端服务对比

supervisorctl status congcong-staging-api
# congcong-staging-api RUNNING

curl -sS http://127.0.0.1:8002/health
# {"status":"ok"}

三、数据库对比

DATABASE_URL=mysql+aiomysql://congcong_staging:<staging_password>@127.0.0.1:3306/congcong_staging?charset=utf8mb4

• 预发库来自正式库全量复制，适合做接近真实场景的验收。
• 预发库不要回写正式库。
• 后续正式库结构有迁移时，预发环境也要执行 alembic upgrade head。
• 如需重新同步正式数据，应先备份或确认可以覆盖 congcong_staging。

四、Redis 对比

预发环境与正式环境 Redis DB 已隔离，避免 WebSocket 设备注册、Celery 任务结果、普通缓存互相污染。

五、部署方式对比

ssh root@121.41.105.67 "bash /opt/congcong/deploy/deploy_backend.sh"
ssh root@121.41.105.67 "bash /opt/congcong/deploy/deploy_backend_staging.sh"

5.1 预发布前端部署

https://staging.florist-saas.com/ 是预发布前端访问域名；它对应的服务器静态部署目录是 /www/wwwroot/staging.florist-saas.com。

预发布前端不发布到 /opt/congcong-staging/backend，也不是只配置后端端口。前端 frontend-v2 本地打包后，把 dist/ 覆盖到 /www/wwwroot/staging.florist-saas.com，Nginx 再把同一域名下的 API/WS 请求转发到预发布后端。

cd D:\deliverables\flowerShop\frontend-v2
powershell -ExecutionPolicy Bypass -File .\deploy\deploy_frontend_v2_staging_local.ps1

5.2 前端部署对比

预发布前端的核心区别是“静态目录换成 /www/wwwroot/staging.florist-saas.com，后端转发换成 127.0.0.1:8002”。业务路径不改，避免客户端测试时还要改 URL path。

六、Webhook 对比

backend-staging 只用于区分“部署预发后端”的 Webhook，不是业务 API 或客户端 WebSocket 路由。业务侧预发访问仍保持与正式一致的路径，只需要把域名从 platform.florist-saas.com 换成 staging.florist-saas.com，例如 /api/v1/... 和 /ws/... 都不需要改路径。

七、服务器域名与 Nginx

7.1 部署服务器

7.2 正式生产已部署域名

7.3 预发公网域名状态

7.4 客户端路径保持一致

当前预发后端已经确认服务器本机与公网域名访问正常。正式域名和预发域名按 Nginx server_name 分流：正式 /api/、/ws/ 仍走 127.0.0.1:8000；只有 staging.florist-saas.com 走 127.0.0.1:8002，不存在端口冲突。

八、已实施事项

九、MCP 排查现状

"mcpServers": {}

示例配置中保留了 github 和 postgres 两个默认禁用的 MCP 配置。当前能确认的是：AI Agent 项目支持 MCP，但线上没有启用 MCP server，也没有发现独立 MCP 服务进程。

十、下一步建议