feat(script): 添加远程程序更新PowerShell脚本

- 实现SSH连接测试和服务器信息获取功能
- 添加磁盘空间检查和系统类型选择界面
- 集成数据库备份和更新报告生成功能
- 提供更新包上传和服务备份框架
- 实现日志记录和错误处理机制
- 添加配置文件管理和用户交互界面

AuxiliaryTool/ScriptTool/RemoteUpdate/待确认事项.md

+# 远程更新脚本 - 待确认事项
+
+## 文档说明
+- 脚本路径：`AuxiliaryTool/ScriptTool/RemoteUpdate/remote_update.ps1`
+- 创建时间：2026-03-11
+- 状态：基础框架已完成，部分功能需完善
+
+---
+
+## 当前实现状态
+
+### 已完成功能 ✅
+
+| 功能模块 | 状态 | 说明 |
+|----------|------|------|
+| 脚本初始化 | ✅ 完成 | 目录创建、全局变量、编码设置 |
+| 用户输入服务器信息 | ✅ 完成 | IP、端口、用户名、密码输入 |
+| SSH连接测试 | ✅ 完成 | 30秒超时，3次重试机制 |
+| 获取服务器信息 | ✅ 完成 | OS、架构、时间、磁盘空间、平台类型 |
+| 磁盘空间检查 | ✅ 完成 | 小于5GB退出 |
+| 系统类型选择 | ✅ 完成 | 4种系统类型选择 |
+| 更新类型选择 | ✅ 完成 | 3种更新类型选择 |
+| 创建更新目录 | ✅ 完成 | /home/update，重试3次 |
+| 上传文件功能 | ✅ 完成 | 使用pscp.exe上传 |
+| 数据库备份 | ✅ 完成 | 上传脚本、执行、导出 |
+| 服务包备份框架 | ✅ 完成 | 函数已实现 |
+| 执行更新脚本 | ✅ 完成 | 上传脚本、执行、获取返回值 |
+| 生成更新报告 | ✅ 完成 | Markdown格式报告 |
+| 日志输出 | ✅ 完成 | INFO/WARN/ERROR/OK四个级别 |
+| 错误处理 | ✅ 完成 | 全局try-catch |
+
+---
+
+## 待完善功能 ⚠️
+
+### 1. 更新包上传逻辑（步骤9）
+
+#### 当前代码状态
+```powershell
+# 步骤9：上传更新包
+# 这里需要根据系统类型和更新类型选择对应的更新包
+# 暂时跳过，待更新包准备好后实现
+Write-LogWarn "更新包上传功能需要根据具体配置实现"
+```
+
+#### 需要确认的内容
+
+| 确认项 | 选项 | 说明 |
+|--------|------|------|
+| **更新包来源** | 选项A: 从 `update_package_new.json` 读取 | 根据系统类型和更新类型获取本地包路径 |
+| | 选项B: 固定命名规则 | 如：`packages/{系统类型}_{更新类型}.zip` |
+| | 选项C: 用户手动指定 | 每次运行时提示用户输入包路径 |
+| **上传前校验** | 是否需要校验文件存在性 | 文件不存在时是否报错退出 |
+
+#### 场景示例
+
+**用户选择**：预定系统 + 前端更新
+
+**需要明确**：
+- 本地更新包路径是什么？
+- 例如：`./front/预定系统_前端.zip` 或其他？
+
+---
+
+### 2. 服务包备份逻辑（步骤11）
+
+#### 当前代码状态
+```powershell
+# 步骤11：备份服务包
+# 这里需要根据配置获取需要备份的服务路径
+# 暂时跳过，待配置完善后实现
+Write-LogWarn "服务包备份功能需要根据具体配置实现"
+```
+
+#### 需要确认的内容
+
+| 确认项 | 选项 | 说明 |
+|--------|------|------|
+| **备份路径来源** | 选项A: 从 `update_type_mapping.json` 读取 | 根据平台类型+系统类型+更新类型获取服务路径 |
+| | 选项B: 从 `update_package_old.json` 读取 | 获取旧版本服务路径 |
+| | 选项C: 固定配置 | 预先定义好各系统的备份路径 |
+| **备份范围** | 选项A: 只备份即将更新的服务 | 前端更新只备份前端相关目录 |
+| | 选项B: 备份所有相关服务 | 全量备份该系统的所有服务 |
+| **备份失败处理** | 选项A: 备份失败则退出程序 | 确保备份成功才继续 |
+| | 选项B: 备份失败仅警告，继续执行 | 允许无备份更新 |
+
+#### 配置文件结构参考
+
+**update_type_mapping.json** 中已有配置结构：
+```json
+{
+  "新统一平台": {
+    "预定系统": {
+      "前端更新": {
+        "ai_services_path": "/data/services/web/pc/pc-vue2-ai",
+        "back_services_path": "/data/services/web/pc/pc-vue2-backstage",
+        ...
+      }
+    }
+  }
+}
+```
+
+**问题**：
+- 选择"预定系统"+"前端更新"时，是备份所有 `*_services_path` 还是有其他规则？
+
+---
+
+### 3. 更新包与服务包的关联关系
+
+#### 待明确
+
+```
+用户选择：预定系统 + 前端更新
+         ↓
+    1. 上传的更新包是哪个文件？
+         └── 路径：？
+
+    2. 服务器上需要备份哪些目录？
+         └── 路径列表：？
+
+    3. 更新脚本需要什么参数？
+         └── 参数：前端更新
+```
+
+---
+
+## 配置文件现状
+
+### 已有的配置文件
+
+| 文件 | 状态 | 用途 |
+|------|------|------|
+| `config/update_type_mapping.json` | ✅ 存在 | 服务路径映射（前端/后端各目录路径） |
+| `config/update_package_old.json` | ✅ 存在 | 旧版本服务路径映射 |
+| `config/update_package_new.json` | ✅ 存在 | 新版本本地包路径（./front, ./back） |
+
+### update_package_new.json 内容
+```json
+{
+  "前端": "./front",
+  "后端": "./back"
+}
+```
+
+**问题**：这个文件的含义是什么？
+- `./front` 目录下是否存放了前端更新包？
+- 更新包的命名规则是什么？
+
+---
+
+## 建议的实现方案
+
+### 方案A：基于配置文件的自动化方案
+
+**假设**：
+1. `./front` 目录下存放前端更新包，命名规则：`{系统类型}.zip`
+2. `./back` 目录下存放后端更新包，命名规则：`{系统类型}.zip`
+3. 备份时从 `update_type_mapping.json` 读取对应的服务路径
+
+**实现逻辑**：
+```
+预定系统 + 前端更新
+    ↓
+上传：./front/预定系统.zip
+备份：从 update_type_mapping.json 读取"新统一平台.预定系统.前端更新"下的所有路径
+```
+
+### 方案B：用户手动指定方案
+
+**实现**：
+- 提示用户输入本地更新包路径
+- 提示用户输入需要备份的服务器目录（或从配置选择）
+
+### 方案C：混合方案（推荐）
+
+**实现**：
+1. 优先尝试从配置自动识别
+2. 配置不存在时提示用户手动输入
+
+---
+
+## 需要反馈的信息
+
+请确认以下内容，以便完善脚本：
+
+1. **更新包路径规则**：
+   - 本地更新包存放在哪个目录？
+   - 命名规则是什么？
+
+2. **服务备份路径规则**：
+   - 是否从 `update_type_mapping.json` 读取？
+   - 选择"前端更新"时需要备份哪些目录？
+
+3. **如果暂时不需要实现**：
+   - 这两个功能是否可以留空，后续按需补充？
+
+---
+
+## 当前脚本可用性
+
+### 可以正常使用的功能
+- ✅ 服务器连接测试
+- ✅ 服务器信息获取
+- ✅ 磁盘空间检查
+- ✅ 系统类型选择
+- ✅ 更新类型选择
+- ✅ 数据库备份（需 backup_db.sh 脚本）
+- ✅ 更新脚本执行（需 service_update.sh 脚本）
+- ✅ 报告生成
+
+### 暂时跳过的功能
+- ⚠️ 更新包自动上传（需确认路径规则）
+- ⚠️ 服务包自动备份（需确认备份范围）
+
+### 结论
+**当前脚本框架完整，核心功能可用，待确认路径规则后可补充完善。**
+
+---
+
+*文档创建时间：2026-03-11*
+*待反馈确认*