1. 环境与链路

诊断时间为 2026 年 9 月 19 日。以下配置只代表当时部署，不代表后续版本的默认行为。示例以 example.com 替代真实域名，不包含认证口令、令牌、私钥或用户会话数据。

DSH 的隧道已从软路由移到 DSH 主机，frpc 使用 host 网络连接本机回环地址。DSH 保持监听 127.0.0.1:3080，通过 trustedHosts 接受公网域名。旧的 13080 → 3080 Node 转发方案不再承载访问。

RustDesk 原生客户端使用独立的 ID、打洞和中继端口，不经过上图中的 frp HTTP 隧道；Web Client 另有 Caddy 代理的 WebSocket 入口。

2. DSH 反复断连：证据与边界

2.1 现象

• 本地地址访问稳定，多台电脑通过公网域名访问都会反复重连。
• 问题出现时 DSH 主进程并非持续崩溃重启。
• 公网链路能够建立 WebSocket，并非完全不支持 Upgrade。
• Caddy 和 frps 日志出现过 unexpected EOF、context canceled 和 EOF。

日志里的 SSE /plugins/events 与 WebSocket /api/remote.mux 是不同连接。不能把所有 EOF 都算作 WebSocket 故障，刷新页面和服务重启也会关闭请求。

2.2 当时实现的心跳机制

检查已安装的 @deepseek-ai/dsh-api-gateway 运行代码，发现：

默认 websocketHeartbeatIntervalMs = 2000
MAX_MISSED_HEARTBEATS = 2
收到 Pong 后将未应答计数清零
达到阈值后执行 socket.terminate()

在定时器正常运行的情况下，短暂的几秒停顿就可能触发关闭。不能只用连接寿命是否接近 2 秒的整数倍来判定原因。

2.3 已观察到什么

| 证据 | 可以得出的结论 | 不能得出的结论 |
|

一、背景与目标

定制系统上的软件版本、动态库和运行环境通常经过整体验证。为了编译一个 Go 项目去更换 yum/apt 软件源，或者升级系统已有组件，风险往往大于收益。另一方面，构建服务器的网络条件也不一定稳定，完全依赖公网会让发布流程失去可预期性。

这套方案遵循以下原则：

1. 不安装或升级系统软件，不修改系统软件源。
2. Go 版本和工具链校验值由仓库固定。
3. 有网时使用模块代理，但不自动修改 go.mod 和 go.sum。
4. 无网或在线编译失败时，整体回退到共享 vendor。
5. 只构建指定的三个服务，不扫描和发布其他模块。
6. 在临时目录完成全部编译，成功后再替换正式产物。

二、整体流程

这里的“在线”仅指 Go 模块依赖解析。脚本不会执行 git pull、go get 或 go mod tidy，也不会动态更新业务代码。

三、构建目录设计

项目的 Go 构建入口位于：

src_go/build/
├── build.sh
├── README.md
├── go.work
├── go.work.sum
├── go_list.txt
├── toolchain.env
├── runtime/
│   ├── gocontrol.sh
│   ├── cygfileweb.sh
│   ├── cygauditweb.sh
│   └── cygimagealgoweb.sh
├── toolchains/
│   └── go1.25.12.linux-amd64.tar.gz
└── vendor/
    ├── modules.txt
    └── ...

首次执行后会在本地生成缓存：

src_go/build/.cache/
├── toolchains/
│   └── go-1.25.12/
├── go-build/
├── gopath/
└── work/

.cache/ 只是当前工作区的解压和编译缓存，不应提交到版本管理。删除它不会丢失源码，下次构建只会重新解压工具链并生成缓存。

四、固定 Go 工具链

toolchain.env 锁定构建工具版本、归档文件名和 SHA256：

GO_VERSION="1.25.12"
GO_ARCHIVE="go1.25.12.linux-amd64.tar.gz"
GO_ARCHIVE_SHA256="234828b7a89e0e303d2556310ee549fbcf253d28de937bac3da13d6294262ac1"

构建前可以先做轻量检查：

cd src_go/build
./build.sh --check

检查项包括：

• 当前主机必须是 Linux x86_64。
• 内置 Go 归档必须存在，SHA256 必须一致。
• 共享 vendor/modules.txt 必须存在。
• 三个目标模块都必须包含 go.mod 和 main.go。
• 四个运行脚本必须完整。

通过校验后，工具链被解压到项目缓存目录，而不是 /usr/local/go 或其他系统目录。脚本还会设置：

GOTOOLCHAIN=local
GOENV=off
CGO_ENABLED=0
GOOS=linux
GOARCH=amd64

GOTOOLCHAIN=local 防止 Go 根据模块声明自动下载另一套工具链，GOENV=off 避免用户全局 Go 配置干扰本次构建。

五、管理三个目标服务

go_list.txt 是唯一的目标清单：

sunri-cygfileweb
sunri-cygauditweb
sunri-cygimagealgoweb

脚本会将模块名前缀 sunri- 去掉，生成下列产物：

| 源码模块 | 可执行文件 |
|

一、背景与目标

目标服务器通常不能稳定访问公网，也不适合通过 yum、apt 或替换软件源来升级 Java、Maven、Git 等基础工具。对于已经交付的定制系统，修改系统环境还可能影响同机运行的其他程序。

因此，这套方案遵循以下原则：

1. 构建工具随项目固定，不依赖服务器预装版本。
2. 工具链解压到项目缓存，不写 /usr、/opt 等系统目录。
3. Maven 使用项目独立的本地仓库，不修改或污染 ~/.m2。
4. 加密工具优先使用仓库内置源码归档，不要求构建机安装 Git，也不在脚本中保存凭据。
5. 只构建 cygcenterweb 和 cygsignsrvweb，避免产生无关服务。
6. 先在临时目录完成编译、收集、加密和校验，全部成功后再替换正式产物。

这里的“离线”需要分成两层理解：

• 工具链离线：JDK、Maven 和加密工具源码都由仓库提供，不访问公网。
• 业务依赖解析：如果项目独立 Maven 仓库还是空的，第一次构建仍需要访问可用的内网 Maven 制品库。缓存完整后才可以在断网环境重复构建。

二、整体流程

构建脚本位于：

src_java/package/build.sh

最终产物位于：

binary/java/
├── bin/
│   ├── javacontrol.sh
│   ├── cygcenterweb.sh
│   └── cygsignsrvweb.sh
└── jar/x64/
    ├── cygcenterweb.jar
    ├── cygsignsrvweb.jar
    └── libs/
        ├── cygcenterweb-requirements.txt
        ├── cygsignsrvweb-requirements.txt
        └── *.jar

三、构建目录设计

构建相关目录如下：

src_java/package/
├── build.sh
├── README.md
├── settings.xml
├── toolchain.env
├── runtime/
│   ├── javacontrol.sh
│   ├── cygcenterweb.sh
│   └── cygsignsrvweb.sh
└── toolchains/
    ├── openjdk-8u171-linux-x64.tar.gz
    ├── apache-maven-3.6.3-bin.tar.gz
    └── sunri-jar-encrypt-fe837986.tar.gz

执行后还会出现本地缓存：

src_java/package/.cache/
├── downloads/
├── toolchains/
├── m2-repository/
└── work/

.cache/ 只服务于当前工作区，不应提交版本管理。它包含解压后的工具链、独立 Maven 仓库和单次构建临时目录。

把 JDK 和 Maven 归档提交到项目会增大仓库体积，但对于无法访问公网、又不能调整系统环境的构建服务器，这是更可控的选择。后续如果有稳定的内网制品库，也可以把归档迁移到制品库，但必须继续保留版本锁定和 SHA256 校验。

四、固定构建输入

所有关键版本集中在 toolchain.env 中，不由构建机当前环境决定：

| 组件 | 固定版本 | SHA256 |
|

• sunri-service-auth-spi：认证、Token、权限和资源的 Service Bus 接口定义。
• sunri-service-auth：账号校验、JWT 签发、实时库会话、角色权限位和资源关系实现。
• sunri-web-center：HTTP 登录入口、请求拦截器、@ApiRight 接口鉴权和菜单过滤。

本文描述的是平台现状，不把它替换成 Spring Security/RBAC 的标准实现。

1. 先看结论

平台的核心授权链不是“用户 -> 角色 -> 权限记录 -> 接口”这种普通关联表模型，而是：

用户 -> 单个角色 -> 角色的 64 位权限位图 -> 权限位集合
                                         |
                                         +-> 菜单所需权限位
                                         +-> API 所需权限位

登录成功后，角色的 ROLEAUTHORITY 位图会被拆成 Set<Integer>。这个权限集合会同时：

1. 返回给 Web Center；
2. 写入实时库的登录会话；
3. 首次校验受保护请求时缓存在 Web Center 本地；
4. 用于过滤菜单；
5. 用于 API 请求鉴权。

2. 核心关系图

2.1 主干关系

| 起点 | 终点 | 实际字段/规则 | 说明 |
|

1. 项目概述

全景监控模块是 PR7050 系统中用于实时展示变电站设备状态的核心功能模块。它通过组态画面的形式，将设备的遥测、遥信、遥控、遥设等实时数据以图形化方式呈现给用户，支持设备状态监控、遥控操作、告警展示等功能。

核心特点：

• 图形化展示：通过组态画面直观展示设备状态
• 实时数据刷新：支持定时轮询和 MQ 推送两种刷新机制
• 多级导航：顶部Tab菜单 + 左侧树提供设备分类导航
• 缓存优化：文件缓存和内存缓存双重优化加载性能

2. 整体数据加载流程

组态画面的数据加载分为五个主要阶段，形成完整的数据闭环：

阶段1：获取顶部Tab菜单 → 阶段2：加载左侧导航树 → 阶段3：获取画面属性 → 阶段4：获取实时数据 → 阶段5：定时刷新/MQ推送

2.1 阶段一：获取顶部Tab菜单

目的：获取全站总览图列表，作为一级导航菜单

涉及接口：

| 接口路径 | 请求方式 | 作用 |
| :

1. 文档范围

涉及的当前 PR7050 文件：

• src_java/package/build.sh：Java 平台、应用、压缩加密工具的主打包入口。
• src_java/package/jar_list.txt：打包后需要收集并加密的 Spring Boot 服务 Jar 清单。
• binary/java/bin/encrypt/*.xml：每个服务压缩时需要保留在服务 Jar 内的依赖清单。
• src_java/tool/sunri-package-compress-xjar/src/main/java/com/sunri/Main.java：XJar 加密密码、加密 include 规则和配置读取逻辑。
• src_java/tool/sunri-package-compress-xjar/src/main/java/com/sunri/JarUtil.java：服务 Jar 压缩、公共依赖抽取和 *-requirements.txt 生成逻辑。
• binary/java/bin/javacontrol.sh：Java 服务 start、stop、restart 控制脚本。

2. Java 打包流程

在 PR7050 根目录下，Java 打包入口位于 src_java/package/build.sh。脚本通过自身路径计算 PROJECT_ROOT，实际 Java 工程根为 /home/liumangmang/IdeaProjects/PR7050/V1.00/src_java。

总体流程步骤

1. 清理旧产物：执行 clean_stale_java_outputs，先删除旧 Jar、XJar 中间文件和旧 requirements。
2. 架构检测：通过 uname -m 选择 jdk-x64 或 jdk-arm，并设置 Maven 路径。
3. 同步加密 XML：从 binary/java/bin/encrypt 同步到 src_java/package/java/bin/encrypt。
4. 编译 Platform：进入 src_java/platform 执行 mvn clean install -DskipTests -T 1C。
5. 编译 Platapp：进入 src_java/platapp 执行 mvn clean package -DskipTests -T 1C。
6. 收集服务 Jar：按 jar_list.txt 在 platform 和 platapp 的 target 目录查找并复制。
7. 压缩加密：构建并执行 sunri-package-compress-xjar，生成加密后的服务 Jar。
8. 同步到 binary：将加密 Jar 和 common 依赖复制到 binary/java 运行目录。

2.1 清理旧 Java 输出

build.sh 开头调用 clean_stale_java_outputs。它会先创建必要目录，再删除下列旧文件，避免上一次构建残留影响本次打包：

• src_java/package/java/jar/x64_raw/*.jar
• src_java/package/java/jar/x64_compress/*.jar
• src_java/package/java/jar/x64/*.jar、*.xjar、xjar.go、compress-xjar.config
• binary/java/jar/x64/*.jar
• src_java/package/java/lib/common/*.jar 与 *-requirements.txt
• binary/java/lib/common/*.jar 与 *-requirements.txt

2.2 关键打包命令

cd /home/liumangmang/IdeaProjects/PR7050/V1.00/src_java/package
./build.sh

脚本内部执行的 Maven 命令：

cd /home/liumangmang/IdeaProjects/PR7050/V1.00/src_java/platform
mvn clean install -DskipTests -T 1C

cd /home/liumangmang/IdeaProjects/PR7050/V1.00/src_java/platapp
mvn clean package -DskipTests -T 1C

⚠ 注意： build.sh 当前跳过测试，适合打包流程。若改动源码，应按受影响模块另行执行最小测试命令。

3. 压缩与 XJar 加密

压缩加密工具位于 src_java/tool/sunri-package-compress-xjar。打包脚本会编译该工具，将 sunri-package-compress-xjar-1.0-jar-with-dependencies.jar 复制到 src_java/package/java/tools，再由模板生成 compress-xjar.config。

3.1 配置文件生成

模板 src_java/package/java/tools/model_compress-xjar.config 中的 {项目全路径} 会被替换为 /home/liumangmang/IdeaProjects/PR7050/V1.00/src_java。生成后的主要目录如下：

| 配置项 | 当前 PR7050 路径 | 作用 |
| :

1. 总体流程

整个流程从 build.sh 开始，先构建 Java 模块，再按清单提取业务 fat jar，随后用压缩工具拆分公共依赖，再使用 XJar 加密，最后把产物同步到 binary/java 运行目录。启动时不是直接执行 java -jar，而是通过 xjar java ... -jar 服务.jar 解密运行。

流程步骤

1. build.sh: 准备 JDK/Maven，同步 encrypt XML
2. Maven Build: 构建 platform 与 platapp
3. x64_raw: 按 jar_list.txt 提取原始 fat jar
4. compress: 拆分 BOOT-INF/lib 依赖
5. lib/common: 输出公共 jar 与 requirements.txt
6. XJar: 加密压缩后的服务 jar
7. binary: 同步 jar 与公共依赖到运行目录
8. startup: xjar java 启动，动态加载公共依赖

一句话概括：
打包阶段把业务 jar 变小并加密，启动阶段用 XJar 解密运行，再由 sunri-spring-classload 把拆出去的公共依赖加载回来。

2. 构建与提取 Jar

入口脚本位于：
/home/liumangmang/IdeaProjects/PR7950/V1.00_2024/src_java/package/build.sh

执行入口

cd /home/liumangmang/IdeaProjects/PR7950/V1.00_2024/src_java/package
bash build.sh

环境准备

脚本根据机器架构选择内置 JDK，并使用项目自带 Maven。

| 项目 | 路径/规则 |
| :

重点只讲三块：

1. 命令面板的进阶工作流
2. 配置文件分层治理（User / Workspace / Profile）
3. 可复用的进阶 JSON 模板

1. 命令面板进阶：把常用动作变成肌肉记忆

命令面板入口不变：Ctrl + Shift + P（Windows / Linux）。

建议只记住下面这组高频命令：

1. >Preferences: Open User Settings (JSON)
2. >Preferences: Open Workspace Settings (JSON)
3. >Preferences: Open Keyboard Shortcuts (JSON)
4. >Tasks: Configure Task
5. >Developer: Reload Window
6. >Profiles: Create Profile
7. >Extensions: Show Installed Extensions

实战思路：遇到任何需求，先用命令面板搜“动词 + 目标”，比如 open settings json、create profile。

2. 配置治理模型：谁该放在哪里

2.1 User settings（全局）

• Windows: %APPDATA%\\Code\\User\\settings.json
• Linux: ~/.config/Code/User/settings.json

放“个人偏好”：字体、自动保存、终端默认 shell、编辑体验。

2.2 Workspace settings（项目）

• 项目路径：.vscode/settings.json

放“项目约束”：缩进、格式化策略、特定语言规则、排除目录。

2.3 Profile（场景）

Profile 适合“多工作模式”用户，例如：

• Frontend：前端开发扩展 + 偏好
• Backend：后端开发扩展 + 偏好
• Minimal：低干扰写作/阅读模式

建议：

• 固定偏好放 User
• 项目规范放 Workspace
• 场景差异放 Profile

3. keybindings.json：给命令面板加速

打开方式：

• Ctrl + Shift + P
• 输入 Open Keyboard Shortcuts (JSON)

示例（Windows / Linux 通用）：

[
  {
    "key": "ctrl+alt+r",
    "command": "workbench.action.reloadWindow"
  },
  {
    "key": "ctrl+alt+,",
    "command": "workbench.action.openSettingsJson"
  },
  {
    "key": "ctrl+alt+t",
    "command": "workbench.action.tasks.runTask"
  }
]

注意：如果快捷键冲突，VSCode 会以后定义或更具体 when 条件为准。

4. 进阶 settings.json 模板（Windows + Linux）

下面模板建议放在 User 级，并按你环境微调：

{
  "editor.fontSize": 14,
  "editor.lineHeight": 1.7,
  "editor.tabSize": 2,
  "editor.wordWrap": "on",
  "editor.minimap.enabled": false,
  "editor.bracketPairColorization.enabled": true,

  "files.autoSave": "onFocusChange",
  "files.trimTrailingWhitespace": true,
  "files.insertFinalNewline": true,
  "files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/node_modules/**": true,
    "**/dist/**": true
  },

  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.codeActionsOnSave": {
    "source.fixAll": "explicit",
    "source.organizeImports": "explicit"
  },

  "terminal.integrated.defaultProfile.windows": "PowerShell",
  "terminal.integrated.defaultProfile.linux": "bash",

  "workbench.startupEditor": "none",
  "workbench.editor.enablePreview": false,
  "workbench.tree.indent": 16
}

如果你不用 Prettier，把 editor.defaultFormatter 改成你实际使用的扩展 ID。

5. Workspace 模板：把项目规范写死

建议每个项目都放一个最小 .vscode/settings.json：

{
  "editor.tabSize": 2,
  "editor.insertSpaces": true,
  "editor.detectIndentation": false,
  "files.eol": "\n"
}

这样团队成员打开项目时，基础编辑行为就能统一。

6. 命令面板 + Task：一键执行项目动作

进阶建议：把常用命令（如构建、测试）写进 Task，再通过命令面板触发。

.vscode/tasks.json 示例：

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "docs:build",
      "type": "shell",
      "command": "npm run docs:build",
      "group": "build",
      "problemMatcher": []
    }
  ]
}

触发方式：

1. Ctrl + Shift + P
2. 输入 Run Task
3. 选择 docs:build

7. 常见坑与排查

7.1 改了配置却没生效

先执行 Developer: Reload Window，再验证。

7.2 User 和 Workspace 打架

按“项目优先”原则，检查 .vscode/settings.json 是否覆盖了 User。

7.3 JSON 报错

确保：

• 不要尾逗号
• 全部键名和字符串使用双引号
• 文件是合法 JSON（不是 JSONC 风格时不要写注释）

8. 进阶完成标准

• 能通过命令面板完成设置、任务、重载
• 能区分 User / Workspace / Profile 三层职责
• 有自己的 keybindings.json 高频快捷键
• 有项目级 .vscode/settings.json 规范
• 能用 tasks.json 一键触发常用命令

做到这 5 点，VSCode 就从“编辑器”变成你的“稳定开发操作台”。

1. VSCode 的基本概念
2. 命令面板怎么高频使用
3. 不进图形化设置，直接改 settings.json

1. 先认识 4 个核心概念

1.1 编辑器 vs 工作区

• 编辑器：你看到和编辑代码的窗口。
• 工作区（Workspace）：当前打开的项目（一个或多个文件夹）。

1.2 配置分层（最重要）

VSCode 的设置是分层生效的：

1. 默认设置（Default）：VSCode 内置。
2. 用户设置（User）：你机器上的全局偏好。
3. 工作区设置（Workspace）：只对当前项目生效。

如果同一个键同时存在，通常是 Workspace 覆盖 User。

1.3 命令面板（Command Palette）

命令面板是 VSCode 的“统一入口”。

• Windows/Linux：Ctrl + Shift + P
• 也可按 F1

你可以在这里执行几乎所有操作，包括打开 JSON 配置。

1.4 扩展不是“额外功能”，而是能力层

VSCode 本体很轻，很多语言能力来自扩展。
但本篇先不讲扩展安装，先把命令面板和配置体系打通。

2. 命令面板：先会这 6 条命令

按 Ctrl + Shift + P 后直接输入：

1. > + Reload Window：重载窗口，配置变更后常用。
2. >Developer: Reload Window：同上，完整命令名。
3. >Preferences: Open User Settings (JSON)：打开全局配置。
4. >Preferences: Open Workspace Settings (JSON)：打开项目配置。
5. >Preferences: Open Default Settings (JSON)：查看默认值（只读参考）。
6. >Files: Auto Save：快速切自动保存策略。

技巧：命令面板支持模糊搜索，你记不全命令名也能找到。

3. settings.json 到底放哪

3.1 用户配置（全局）

• Windows: %APPDATA%\\Code\\User\\settings.json
• Linux: ~/.config/Code/User/settings.json

建议：全局偏好（字体、自动保存、格式化默认行为）放这里。

3.2 工作区配置（项目级）

• 项目根目录：.vscode/settings.json

建议：和项目强相关的配置放这里（例如某项目缩进、格式化器、排除目录）。

4. 用命令面板打开 JSON 配置（不进图形设置）

4.1 打开用户配置

1. Ctrl + Shift + P
2. 输入 Open User Settings (JSON)
3. 回车

4.2 打开工作区配置

1. Ctrl + Shift + P
2. 输入 Open Workspace Settings (JSON)
3. 回车

如果项目里没有 .vscode/settings.json，VSCode 会帮你创建。

5. 可直接粘贴的入门模板

下面这份建议先放在 User settings.json，适用于 Windows + Linux。

{
  "editor.fontSize": 14,
  "editor.tabSize": 2,
  "editor.wordWrap": "on",
  "editor.minimap.enabled": false,

  "files.autoSave": "onFocusChange",
  "files.trimTrailingWhitespace": true,
  "files.insertFinalNewline": true,

  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll": "explicit"
  },

  "terminal.integrated.defaultProfile.windows": "PowerShell",
  "terminal.integrated.defaultProfile.linux": "bash",

  "files.exclude": {
    "**/.DS_Store": true,
    "**/node_modules": true,
    "**/.git": false
  }
}

说明：

• formatOnSave 依赖你安装并启用对应语言的格式化扩展。
• source.fixAll 设为 explicit 更稳，避免每次保存都触发过多修复。
• terminal.integrated.defaultProfile.* 按你的本机实际 shell 调整。

6. User 与 Workspace 怎么分

推荐这套规则：

• 放 User：你个人习惯，跨项目都想保留。
• 放 Workspace：只在当前项目生效的规则。

示例：某项目要求 4 空格缩进，就写到该项目 .vscode/settings.json：

{
  "editor.tabSize": 4,
  "editor.insertSpaces": true
}

7. 常见问题（JSON 配置方式）

7.1 配置不生效

按 Ctrl + Shift + P 执行 Developer: Reload Window，再验证。

7.2 JSON 报错（逗号、引号）

settings.json 必须是合法 JSON。重点检查：

• 最后一项后面不要多逗号
• 键名和字符串值要用双引号

7.3 不确定某个键该写什么

用命令面板打开 Default Settings (JSON) 搜索对应键，按默认文档写。

8. 15 分钟上手清单

• 会用 Ctrl + Shift + P 打开命令面板
• 会打开 User Settings (JSON)
• 会打开 Workspace Settings (JSON)
• 能区分 User 与 Workspace 的生效范围
• 粘贴并调整一份可用的 settings.json
• 配置不生效时会执行 Reload Window

完成以上 6 项，你已经跨过 VSCode 入门阶段。

一、基础导航类快捷键

1.1 标签页管理

| 快捷键 | 功能描述 | 使用场景 |
|

一 问题背景

1.1 初始状态

排查时的核心数据：

• 物理内存: 29GB
• 已使用: 25GB (86%)
• 可用内存: 3.5GB
• Swap: 15GB，几乎耗尽

1.2 主要问题

| 问题 | 严重程度 | 影响 |
|

这篇以 OpenCode 为主视角，把上游仓库 obra/superpowers 的核心要点整理成一篇
可直接照着用的速查。

适合人群：

• 个人单用户场景
• 希望 24 小时在线
• 想接 Telegram 或飞书
• 想一次把常见坑踩完

VNC 单脚本管理与批量下发

1. 目标场景

示例目标机器：

• 10.6.223.223
• 10.6.220.165
• 10.6.221.8
• 10.6.223.233

统一目标：

1. 在远程桌面生成 vnc_ctl.sh
2. 后台运行 x0vncserver
3. 提供开机自启能力
4. 支持状态检查与一键停止
5. 支持批量下发，减少重复操作

2. 管理脚本设计

主脚本：vnc_ctl.sh

支持命令：

• start：启动 VNC
• stop：停止 VNC
• check：检查进程、端口、密码文件与日志
• restart：重启服务
• install-autostart：安装 @reboot 自启
• remove-autostart：移除自启

核心思路：

• 通过 pgrep 精确匹配 x0vncserver 参数定位进程
• 使用 nohup 后台运行并记录日志
• 通过 crontab 注入 @reboot 行实现开机拉起

示例（启动命令段）：

nohup x0vncserver \
  -display ":0" \
  -passwordfile "$HOME/.vnc/passwd" \
  -rfbport "5900" \
  -nevershared \
  -idletimeout 0 \
  >>"$HOME/.vnc/x0vncserver-5900.log" 2>&1 &

3. 批量下发脚本

下发脚本：deploy_to_desktop.sh

用途：把本地脚本按 IP 列表分发到远程桌面目录，并自动加执行权限。

示例命令：

./deploy_to_desktop.sh -f ./vnc_ctl.sh -i 10.6.223.233,10.6.220.165 -u sunri

脚本默认行为：

• 目标目录默认为 /home/<user>/Desktop
• 使用 SSH/SCP 分发
• 分发后自动执行 chmod +x

4. 推荐使用流程

chmod +x ./vnc_ctl.sh ./deploy_to_desktop.sh
./deploy_to_desktop.sh -f ./vnc_ctl.sh -i 10.6.223.233,10.6.220.165 -u sunri

远程执行示例：

ssh sunri@10.6.220.165 "/home/sunri/Desktop/vnc_ctl.sh install-autostart && /home/sunri/Desktop/vnc_ctl.sh start && /home/sunri/Desktop/vnc_ctl.sh check"

5. 测试结论

• 10.6.220.165：下发成功，脚本存在且可执行
• 10.6.223.233：下发失败，原因为 SSH 认证失败（Permission denied）

6. 常见问题排查

• 缺少密码文件：在目标机执行 vncpasswd
• 端口未监听：检查 ~/.vnc/x0vncserver-5900.log
• 开机自启未生效：检查 crontab -l 中 @reboot ... vnc_ctl.sh start ...
• 无法下发：先手动验证 ssh <user>@<ip>

7. 小结

该方案把 VNC 运维拆成两个可复用脚本：

• 单机统一管理生命周期
• 多机统一批量下发

适合内网多台 Linux 机器的日常维护与快速复制部署。

远程 C++ 项目一键全量构建

1. 场景信息

• 目标主机：10.6.223.0
• 项目根目录：/home/sunri/PRS-7950/V1.00_2024
• C++ 源码目录：/home/sunri/PRS-7950/V1.00_2024/src_cxx

2. 先确认连接与路径

先验证 SSH 连通性：

ssh 10.6.223.0

连接后可用 hostname 确认机器身份。

这次排查中，一个关键点是目录名确认：

• 错误路径：/home/sunri/PRS-7950/V1.00_2024/src_cx
• 正确路径：/home/sunri/PRS-7950/V1.00_2024/src_cxx

编译前先核对路径，通常比盲目调整编译参数更有效。

3. 执行增量编译

在源码目录执行：

make -j"$(nproc)"

说明：

• -j"$(nproc)" 表示按 CPU 核心数并行编译
• 若出现 Nothing to be done for 'first'，通常表示该目标已是最新状态（增量构建正常现象）

4. 固化为一键全量构建脚本

在 src_cxx 下创建 build.sh：

#!/usr/bin/env bash
set -euo pipefail

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"

cd "$SCRIPT_DIR"

echo "[build] Cleaning project..."
make clean

echo "[build] Building project (full rebuild)..."
make -j"$(nproc)"

echo "[build] Done."

赋予执行权限：

chmod +x build.sh

5. 日常使用方式

cd /home/sunri/PRS-7950/V1.00_2024/src_cxx
./build.sh

脚本固定执行两步：

1. make clean
2. make -j"$(nproc)"

6. 小结

这套流程的核心不是命令复杂度，而是标准化：

• 先确认路径和环境
• 再把全量构建流程脚本化

后续交付或排障时，只需要统一执行 ./build.sh 即可降低沟通与操作成本。

AlgoSimulation 打包与交付记录

1. 目标与环境

• 编译目标：/home/sunri/IdeaProjects/V2.00/src_cxx/99_TestTool/AlgoSimulation
• 编译机：10.6.221.8
• 参考机：10.6.220.186
• 约束：08_Preview 已同步完成，本次仅处理编译、链接与打包

2. 基础编译流程

export PRJHOME=/home/sunri/IdeaProjects/V2.00
export CYGHOME=/home/sunri/08_Preview/linx80
cd /home/sunri/IdeaProjects/V2.00/src_cxx/99_TestTool/AlgoSimulation
qmake AlgoSimulation.pro
make -j4

3. 链接问题与修正

链接阶段出现 OpenSSL 相关符号版本不匹配（OPENSSL_1_1_0d）。

原因是 libmosquitto、libcurl、libssh2 依赖的 OpenSSL 版本，与系统默认搜索到的 libssl/libcrypto 不一致。

修正方式：通过 qmake 注入链接参数，显式指定 gmssl 库并关闭 as-needed 提前裁剪。

export PRJHOME=/home/sunri/IdeaProjects/V2.00
export CYGHOME=/home/sunri/08_Preview/linx80
cd /home/sunri/IdeaProjects/V2.00/src_cxx/99_TestTool/AlgoSimulation
make clean
qmake "QMAKE_LFLAGS+=-Wl,--no-as-needed" \
      "LIBS+=/usr/local/gmssl/lib/libssl.so.1.1 /usr/local/gmssl/lib/libcrypto.so.1.1" \
      AlgoSimulation.pro
make -j4

编译产物：/home/sunri/IdeaProjects/V2.00/binary/linx80/bin/AlgoSimulation

4. 独立目录打包

目标目录：/home/sunri/Desktop/AlgoSimulation_tool

TOOL=/home/sunri/Desktop/AlgoSimulation_tool
BIN=/home/sunri/IdeaProjects/V2.00/binary/linx80/bin/AlgoSimulation

rm -rf "$TOOL"
mkdir -p "$TOOL/bin" "$TOOL/lib"
cp -f "$BIN" "$TOOL/bin/"

ldd "$BIN" | awk '/=> \/home\/sunri\// {print $3} /=> \/usr\/local\/gmssl\// {print $3}' | sort -u | while read -r so; do
  cp -f "$so" "$TOOL/lib/"
done

cp -f /usr/local/gmssl/lib/libssl.so.1.1 "$TOOL/lib/"
cp -f /usr/local/gmssl/lib/libcrypto.so.1.1 "$TOOL/lib/"

启动脚本 run_AlgoSimulation.sh：

#!/usr/bin/env bash
set -e
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
export LD_LIBRARY_PATH="$SCRIPT_DIR/lib:${LD_LIBRARY_PATH:-}"
exec "$SCRIPT_DIR/bin/AlgoSimulation" "$@"

5. 验证结果

缺库检查：

LD_LIBRARY_PATH=/home/sunri/Desktop/AlgoSimulation_tool/lib \
ldd /home/sunri/Desktop/AlgoSimulation_tool/bin/AlgoSimulation | grep "not found"

• 结果：无输出（未发现缺失依赖）

启动冒烟：

• 在无图形会话环境下提示 cannot connect to X server
• 结论：当前阻塞点是图形环境，不是依赖缺失

6. 交付清单

• /home/sunri/Desktop/AlgoSimulation_tool/bin/AlgoSimulation
• /home/sunri/Desktop/AlgoSimulation_tool/lib/
• /home/sunri/Desktop/AlgoSimulation_tool/run_AlgoSimulation.sh

7. 后续建议

若后续仍出现符号版本或缺库问题，优先按缺失项从 10.6.220.186 精准补齐，避免全量同步带来的不可控差异。