● 完全正确！标准的二次开发工作流程就是这样的：

  🔄 正确的工作流程

  ┌─────────────────┐         ┌──────────────────┐         ┌─────────────────┐
  │  官方仓库       │         │  你的仓库         │         │  生产服务器      │
  │  (upstream)     │────┐    │  (origin)        │────────▶│  /opt/sub2api   │
  │  GitHub         │    │    │  git.586vip.cn   │         │                 │
  └─────────────────┘    │    └──────────────────┘         └─────────────────┘
                         │              ▲                           │
                         │              │                           │
                         │              │ push                      │ pull
                         │              │                           │
                         │    ┌─────────┴──────────┐               │
                         └───▶│  本地开发环境       │               │
                   fetch/pull │  (你的 WSL)        │◀──────────────┘
                              │  /mnt/d/tmp/...    │     仅用于测试
                              └────────────────────┘

  ---
  📋 具体操作流程

  1️⃣ 本地环境（你的 WSL - 主要工作区）

  cd /mnt/d/tmp/claude相关/sub2api

  # 查看当前 remote 配置
  git remote -v
  # origin    https://git.586vip.cn/oadmin/sub2api.git
  # upstream  https://github.com/Wei-Shaw/sub2api.git

  # ===== 同步官方更新 =====

  # 1. 拉取官方最新代码
  git fetch upstream

  # 2. 查看官方更新了什么
  git log HEAD..upstream/main --oneline --graph

  # 3. 详细对比差异（重要！）
  git diff HEAD..upstream/main

  # 查看某个文件的差异
  git diff HEAD..upstream/main -- backend/internal/service/gateway_service.go

  # 4. 合并官方更新到你的本地
  git merge upstream/main

  # 5. 如果有冲突，解决冲突
  # (编辑冲突文件，保留你需要的代码)
  git add .
  git commit -m "merge: 合并官方更新 vX.X.X"

  # 6. 推送到你的仓库
  git push origin main

  2️⃣ 服务器环境（生产服务器 - 只拉取你的仓库）

  cd /opt/sub2api-dev

  # 查看 remote（应该只有 origin 指向你的仓库）
  git remote -v
  # origin    https://git.586vip.cn/oadmin/sub2api.git

  # ===== 更新服务器代码 =====

  # 1. 拉取你的仓库最新代码
  git pull origin main

  # 2. 重新部署
  cd deploy
  docker-compose pull
  docker-compose up -d

  # 3. 查看日志确认
  docker-compose logs -f

  ---
  🎯 完整示例场景

  场景：官方发布了 v1.5.0 版本

  第 1 步：本地对比更新

  # 在你的 WSL 中
  cd /mnt/d/tmp/claude相关/sub2api

  # 拉取官方更新
  git fetch upstream

  # 查看更新内容
  git log HEAD..upstream/main --oneline
  # a1b2c3d (upstream/main) feat: 新增 XX 功能
  # d4e5f6g fix: 修复 YY 问题
  # ...

  # 对比差异
  git diff HEAD..upstream/main

  # 如果改动太多，可以查看修改的文件列表
  git diff --name-only HEAD..upstream/main

  # 查看某个关键文件的详细差异
  git diff HEAD..upstream/main -- backend/internal/service/gateway_service.go

  第 2 步：本地合并更新

  # 确保工作区干净
  git status

  # 如果有未提交的修改，先提交
  git add .
  git commit -m "feat: 我的二开功能"

  # 合并官方更新
  git merge upstream/main

  # 如果有冲突
  # <<<<<<< HEAD
  # 你的代码
  # =======
  # 官方代码
  # >>>>>>> upstream/main

  # 手动编辑冲突文件，选择保留哪部分代码
  nano backend/internal/service/gateway_service.go

  # 解决冲突后
  git add .
  git commit -m "merge: 合并官方 v1.5.0 更新"

  第 3 步：推送到你的仓库

  # 推送到你的仓库
  git push origin main

  第 4 步：服务器更新

  # SSH 到服务器
  ssh root@你的服务器IP

  # 进入项目目录
  cd /opt/sub2api-dev

  # 拉取最新代码
  git pull origin main

  # 如果代码有更新，重新部署
  cd deploy
  docker-compose pull
  docker-compose up -d

  # 查看日志
  docker-compose logs -f sub2api

  ---
  ⚠️ 重要注意事项

  ✅ 正确做法

  - ✅ 本地开发：拉取官方更新、对比、合并
  - ✅ 本地测试：确保合并后代码能正常运行
  - ✅ 推送到自己仓库：git push origin main
  - ✅ 服务器拉取：git pull origin main

  ❌ 错误做法

  - ❌ 服务器直接拉取官方代码（跳过本地对比）
  - ❌ 不测试就直接推送到生产
  - ❌ 直接在服务器上修改代码（应该在本地改）

  ---
  📝 快速命令速查

  本地（开发环境）

  # 同步官方更新
  git fetch upstream
  git log HEAD..upstream/main --oneline
  git diff HEAD..upstream/main
  git merge upstream/main
  git push origin main

  服务器（生产环境）

  # 更新代码
  cd /opt/sub2api-dev
  git pull origin main

  # 重新部署
  cd deploy
  docker-compose pull
  docker-compose up -d
  docker-compose logs -f

cd deploy/
  # 如果没有输出，说明需要重新复制
  cp docker-compose.1panel.yml docker-compose.yml

   docker-compose build --no-cache

     docker-compose up -d

  # 或者一条命令
  docker-compose up -d --build
  ---
  现在你可以先在服务器上部署了，后续官方有更新时，就按照上面的流程操作！