星光下的赶路人

ossutil常用操作

Wed, 21 Oct 2026 10:16:32 +0800

ossutil阿里云OSS文件操作工具，可以批量操作文件

下载地址：

windows上直接下载解压后进入解压目录通过cmd命令行操作

重点差异：

配置文件格式不一样（v1：[Credentials]；v2：[default]）

参数风格大体接近，但读取配置、部分高级参数、返回提示、错误码细节有区别

v1 配置文件字段：accessKeyID（大写ID）；v2：accessKeyId（小写Id）

v1 是单二进制老版本；v2 是重构新版，子命令体系有微调

统一说明：

-r：递归

-u：增量，跳过大小/修改时间一致的文件

--forbid-overwrite true：禁止覆盖已有文件

--config-file "xxx"：指定配置文件路径

一、版本查看

v1（1.7.19）

ossutil -v

ossutil version

二、配置相关

v1

生成/交互式配置

ossutil config

配置文件内容模板（v1）

[Credentials]
accessKeyID=xxx
accessKeySecret=xxx
endpoint=http://xxx

指定配置文件执行（你在用的）

ossutil ls oss://bucket --config-file "C:\Users\user14\.ossutilconfig"

v2

交互式配置

ossutil config

配置文件模板（v2）

[default]
accessKeyId=xxx
accessKeySecret=xxx
endpoint=http://xxx

指定配置文件

ossutil ls oss://bucket --config-file "C:\Users\user14\.ossutilconfig"

三、列举 bucket / 列举桶内文件

# 列出所有bucket
ossutil ls --config-file "C:\Users\user14\.ossutilconfig"
# 列出桶内文件（递归）
ossutil ls oss://mybucket/ -r --config-file "C:\Users\user14\.ossutilconfig"

ossutil ls
ossutil ls oss://mybucket/ -r

四、上传文件/文件夹

# 单个文件上传
ossutil cp D:\test.txt oss://mybucket/ --config-file "C:\Users\user14\.ossutilconfig"
# 文件夹递归上传 + 增量
ossutil cp D:\localdir oss://mybucket/dir/ -r -u --config-file "C:\Users\user14\.ossutilconfig"

ossutil cp D:\test.txt oss://mybucket/
ossutil cp D:\localdir oss://mybucket/dir/ -r -u

五、下载文件/文件夹

ossutil cp oss://mybucket/test.txt D:\ --config-file "C:\Users\user14\.ossutilconfig"
ossutil cp oss://mybucket/dir/ D:\localdir/ -r -u --config-file "C:\Users\user14\.ossutilconfig"

ossutil cp oss://mybucket/test.txt D:\
ossutil cp oss://mybucket/dir/ D:\localdir/ -r -u

六、桶之间互拷（同region，服务端复制，不落地本地）✅

# 全量递归复制，增量，不覆盖
ossutil cp oss://src-bucket/ oss://dst-bucket/ -r -u --forbid-overwrite true --config-file "C:\Users\user14\.ossutilconfig"

ossutil cp oss://src-bucket/ oss://dst-bucket/ -r -u --forbid-overwrite true

⚠️ 源末尾必须带 /，代表桶根目录所有对象

七、同步 sync（镜像同步：源删了，目标也删除，谨慎！）

ossutil sync oss://src-bucket/ oss://dst-bucket/ --config-file "C:\Users\user14\.ossutilconfig"
ossutil sync D:\local oss://bucket/dir/ --config-file "C:\Users\user14\.ossutilconfig"

ossutil sync oss://src-bucket/ oss://dst-bucket/
ossutil sync D:\local oss://bucket/dir/

八、删除对象（慎用！）

# 删除单个
ossutil rm oss://mybucket/test.txt --config-file "C:\Users\user14\.ossutilconfig"
# 递归删除目录下全部
ossutil rm oss://mybucket/dir/ -r --config-file "C:\Users\user14\.ossutilconfig"

ossutil rm oss://mybucket/test.txt
ossutil rm oss://mybucket/dir/ -r

九、创建 / 删除 bucket

ossutil mb oss://newbucket --config-file "C:\Users\user14\.ossutilconfig"
ossutil rb oss://newbucket --config-file "C:\Users\user14\.ossutilconfig"

ossutil mb oss://newbucket
ossutil rb oss://newbucket

十、获取文件元信息

ossutil stat oss://mybucket/test.txt --config-file "C:\Users\user14\.ossutilconfig"

ossutil stat oss://mybucket/test.txt

十一、批量命令通用参数（v1、v2 大部分通用）

参数	含义
`-r`	递归目录
`-u`	增量模式，跳过相同文件
`--forbid-overwrite true`	禁止覆盖
`--quiet`	静默输出，少打印日志
`--jobs N`	设置并发数，如 `--jobs 10`

⚠️ 两个版本踩坑重点（非常关键）

不要混用配置文件：v1的配置文件给v2读、v2给v1读，直接报 Credentials 找不到；
跨 region 桶复制：ossutil 本身不支持服务端复制，会自动下载到本地再上传，速度很慢；
你这个兼容S3的私有对象存储，v1 能跑通，v2 不一定能跑通（签名逻辑有差异），所以你现在优先固定 v1.7.19；
cp 是复制（只新增覆盖，不会删目标多余文件）；sync 是镜像（会删除目标独有的文件），迁移备份优先用 cp -r -u。

OpenList 从入门到进阶：Windows 部署、网盘挂载与多用户分享全指南

Fri, 09 Oct 2026 13:17:47 +0800

在网盘限速、多平台割裂的今天，如何用一个统一入口管理阿里云盘、百度网盘、夸克网盘等资源，成了很多人的刚需。OpenList 作为 Alist 的社区分支，凭借开源、透明、支持 40+ 种存储协议的特性，成为了当前最值得折腾的聚合方案之一。

这篇文章整理了从下载安装、网盘挂载，到多用户权限、文件分享的完整流程，希望能帮你少走弯路。

一、OpenList 与 Alist：为什么选它？

简单来说，OpenList 是 Alist 的社区“逃生版”。2025 年 Alist 被出售给第三方公司后，社区对其私有 API 和潜在的数据收集行为产生担忧，部分原贡献者创建了 OpenList 分支。

特性	Alist（被收购后）	OpenList（社区分支）
维护方	不够科技（贵州）公司	OpenList Team，社区驱动
信任度	存在争议	强调透明，代码可审计
核心风险	私有 API 可能泄露 Token	已清除原作者私有 API 链接
授权协议	开源	AGPL-3.0

对于新用户，建议直接选择 OpenList。

二、Windows 部署：下载与启动

下载哪个版本？

在 GitHub Releases 页面，Windows 用户会看到两个包：

openlist-windows-amd64.zip（普通版）：功能完整，适合直接运行 openlist.exe 长期使用。
openlist-windows-amd64-lite.zip（精简版）：体积更小，适合配合 OpenList Desktop 使用，或不需要本地挂载等高级功能。

建议：如果你想直接在浏览器里管理网盘，下载普通版即可。

启动服务

解压后，在 openlist.exe 所在文件夹打开命令行：

openlist.exe server
`</pre>

浏览器访问 `http://localhost:5244` 即可。

> ⚠️ 注意：`nohup` 是 Linux 命令，Windows 下直接运行 `openlist.exe server` 即可。如果想后台运行，可以用 `start /b openlist.exe server`，或使用 NSSM 注册为系统服务。

### 首次登录

默认管理员账号是 `admin`，密码随机生成。查看或重置密码：

<pre>`openlist.exe admin              # 查看管理员信息
openlist.exe admin set 新密码   # 强制修改密码

三、挂载国内网盘

阿里云盘（推荐 OAuth2 方式）

打开官方 API 页面。地址

3. 选择“阿里云盘（OAuth2）”，用手机 App 扫码授权。

4. 复制返回的 refresh_token。

5. 在 OpenList 后台“存储”→“添加”，驱动选择“阿里云盘（OAuth2）”，粘贴令牌，开启“使用在线 API”。

6. 挂载路径自定义，如 /aliyun。

百度网盘

百度网盘有严格的应用沙箱限制：通过 OpenList 只能看到 /apps/bdpan/ 目录下的文件。挂载后如果发现是空的，先确认文件是否在这个目录里。

夸克网盘

需要手动获取 Cookie：

浏览器登录 pan.quark.cn，按 F12 打开开发者工具。
切换到“网络”标签，刷新页面，随意点一个请求。
复制请求头里的 Cookie 字段。
在 OpenList 添加存储时，驱动选“夸克”，粘贴 Cookie，根文件夹 ID 填 0。

⚠️ 夸克网盘在线播放较慢，因为数据需要经过 OpenList 本地代理中转。

四、文件分享

分享方式

生成分享链接：右键文件 → “分享”，可设置有效期和提取码。
WebDAV 共享：在用户设置里开启 WebDAV 权限，对方通过 http://你的IP:5244/dav/ 挂载访问。

OpenList 的强大在于它把散落在各个平台的网盘聚合成了一个统一入口，再通过多用户和权限系统实现了可控的共享。虽然配置过程有一些门槛，但一旦跑通，日常使用会非常顺畅。

Python 实现高德 GCJ-02 转百度 BD-09：MySQL 批量并发处理与断点续跑

Tue, 29 Sep 2026 16:40:11 +0800

在实际的数据治理、地图数据迁移以及零售户地理信息处理中，经常会遇到不同地图厂商之间的坐标系不一致问题。

例如：

高德地图使用 GCJ-02
百度地图使用 BD-09
GPS 原始坐标通常为 WGS-84

如果数据库中的经纬度来自高德地图，而后续业务需要使用百度地图进行展示、空间计算或者区域匹配，就需要先将 GCJ-02 坐标转换为 BD-09。

当数据量比较小时，可以直接逐条转换。

但是如果数据库中有几十万、几百万甚至上千万条坐标数据，逐条处理会非常慢。

本文介绍一种适合实际生产环境的处理方式：

MySQL + Python + 多进程并发 + 批量读取 + 批量更新 + 断点续跑

一、问题背景

假设数据库中存在一张零售户位置表：

CREATE TABLE `t_data_cust` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `cus_name` varchar(255) DEFAULT NULL COMMENT '零售户名称',
  `address` varchar(255) DEFAULT NULL COMMENT '经营地址',
  `mapx` float DEFAULT NULL COMMENT '经度',
  `mapy` float DEFAULT NULL COMMENT '纬度',
  `baidu_longitude` double DEFAULT NULL COMMENT '百度经度',
  `baidu_latitude` double DEFAULT NULL COMMENT '百度纬度',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

其中：

mapx = 高德经度
mapy = 高德纬度

数据类似：

id       mapx          mapy
1        119.036411    35.091783
2        119.027665    35.096810
3        119.024164    35.094040

现在需要将：

GCJ-02
   ↓
BD-09

转换以后保存到：

baidu_longitude
baidu_latitude

二、GCJ-02 和 BD-09 是什么？

在中国互联网地图应用中，经常会接触到几个坐标系。

WGS-84

GPS 常见的全球坐标系。

例如：

119.000000
35.000000

GCJ-02

高德地图、腾讯地图等国内地图服务常见的坐标系。

BD-09

百度地图在 GCJ-02 基础上再次进行偏移后的坐标系。

因此：

WGS-84
   ↓
GCJ-02
   ↓
BD-09

本文只讨论：

GCJ-02 → BD-09

三、GCJ-02 转 BD-09 算法

GCJ-02 转 BD-09 可以直接使用公开的数学转换公式。

Python 实现如下：

import math


def gcj02_to_bd09(lng, lat):
    """
    GCJ-02 转 BD-09

    :param lng: GCJ-02 经度
    :param lat: GCJ-02 纬度
    :return: BD-09 经度、纬度
    """

    x = lng
    y = lat

    z = math.sqrt(x * x + y * y) + \
        0.00002 * math.sin(y * math.pi * 3000.0 / 180.0)

    theta = math.atan2(y, x) + \
            0.000003 * math.cos(x * math.pi * 3000.0 / 180.0)

    bd_lng = z * math.cos(theta) + 0.0065
    bd_lat = z * math.sin(theta) + 0.006

    return bd_lng, bd_lat

测试：

lng = 119.03641110
lat = 35.09178304

bd_lng, bd_lat = gcj02_to_bd09(lng, lat)

print(bd_lng)
print(bd_lat)

四、为什么不能直接逐条查询和更新？

最简单的代码可能是：

for row in rows:

    lng = row["mapx"]
    lat = row["mapy"]

    bd_lng, bd_lat = gcj02_to_bd09(lng, lat)

    cursor.execute(
        """
        UPDATE t_data_cust
        SET baidu_longitude = %s,
            baidu_latitude = %s
        WHERE id = %s
        """,
        (bd_lng, bd_lat, row["id"])
    )

这种方式存在两个明显问题。

1. 数据库交互次数太多

假设有：

1,000,000 条数据

就可能产生：

1,000,000 次 UPDATE

数据库压力比较大。

2. 单线程速度比较慢

即使坐标转换本身非常快：

读取数据库
    ↓
计算
    ↓
UPDATE
    ↓
读取下一条
    ↓
计算
    ↓
UPDATE

整个过程是串行的。

五、优化思路

可以把整个处理过程拆成几个阶段：

MySQL
  │
  │ 批量读取
  ↓
Python
  │
  ├── 进程1
  ├── 进程2
  ├── 进程3
  ├── 进程4
  ├── 进程5
  └── 进程6
  │
  │ GCJ-02 → BD-09
  ↓
批量结果
  │
  ↓
MySQL 批量 UPDATE

核心思想是：

数据库负责数据存储，CPU 多进程负责坐标计算。

六、为什么使用多进程？

Python 中普通的多线程受到 GIL 的影响。

虽然这个坐标转换计算量不算特别大，但是如果数据达到几十万、几百万条，多进程能够更加充分地利用多个 CPU 核心。

例如：

单进程

CPU
└── Python
    └── 处理所有数据

改成：

6 个进程

CPU
├── Process 1
├── Process 2
├── Process 3
├── Process 4
├── Process 5
└── Process 6

每个进程处理自己的一批数据。

七、批量并发处理

下面给出一个完整示例。

首先安装依赖：

pip install mysql-connector-python

如果使用 Conda：

conda activate 你的环境
python -m pip install mysql-connector-python

八、完整代码

import math
import mysql.connector

from concurrent.futures import ProcessPoolExecutor
from mysql.connector import Error


# ============================================================
# MySQL 配置
# ============================================================

DB_CONFIG = {
    "host": "127.0.0.1",
    "port": 3306,
    "user": "root",
    "password": "123456",
    "database": "test",
}


# ============================================================
# GCJ-02 → BD-09
# ============================================================

def gcj02_to_bd09(lng, lat):

    x = lng
    y = lat

    z = math.sqrt(x * x + y * y) + \
        0.00002 * math.sin(
            y * math.pi * 3000.0 / 180.0
        )

    theta = math.atan2(y, x) + \
            0.000003 * math.cos(
                x * math.pi * 3000.0 / 180.0
            )

    bd_lng = z * math.cos(theta) + 0.0065
    bd_lat = z * math.sin(theta) + 0.006

    return bd_lng, bd_lat


# ============================================================
# 单个任务
# ============================================================

def process_batch(batch):

    result = []

    for row in batch:

        row_id = row[0]
        lng = row[1]
        lat = row[2]

        try:

            bd_lng, bd_lat = gcj02_to_bd09(
                float(lng),
                float(lat)
            )

            result.append(
                (
                    bd_lng,
                    bd_lat,
                    row_id
                )
            )

        except Exception as e:

            print(
                f"ID={row_id} 转换失败：{e}"
            )

    return result


# ============================================================
# 创建数据库连接
# ============================================================

def get_connection():

    return mysql.connector.connect(
        host=DB_CONFIG["host"],
        port=DB_CONFIG["port"],
        user=DB_CONFIG["user"],
        password=DB_CONFIG["password"],
        database=DB_CONFIG["database"],
    )


# ============================================================
# 获取待处理数据
# ============================================================

def get_data():

    conn = None
    cursor = None

    try:

        conn = get_connection()

        cursor = conn.cursor()

        sql = """
        SELECT
            id,
            mapx,
            mapy
        FROM t_data_cust
        WHERE mapx IS NOT NULL
          AND mapy IS NOT NULL
          AND baidu_longitude IS NULL
          AND baidu_latitude IS NULL
        """

        cursor.execute(sql)

        rows = cursor.fetchall()

        print(f"待处理数据：{len(rows)} 条")

        return rows

    finally:

        if cursor:
            cursor.close()

        if conn:
            conn.close()


# ============================================================
# 批量更新数据库
# ============================================================

def update_database(results):

    if not results:
        return

    conn = None
    cursor = None

    try:

        conn = get_connection()

        cursor = conn.cursor()

        sql = """
        UPDATE t_data_cust
        SET
            baidu_longitude = %s,
            baidu_latitude = %s
        WHERE id = %s
        """

        cursor.executemany(
            sql,
            results
        )

        conn.commit()

        print(
            f"数据库更新完成：{len(results)} 条"
        )

    except Exception:

        if conn:
            conn.rollback()

        raise

    finally:

        if cursor:
            cursor.close()

        if conn:
            conn.close()


# ============================================================
# 主程序
# ============================================================

def main():

    print("=" * 60)
    print("GCJ-02 → BD-09 批量并发转换")
    print("=" * 60)

    # 读取数据
    rows = get_data()

    if not rows:

        print("没有需要处理的数据")

        return

    # ========================================================
    # 分批
    # ========================================================

    batch_size = 5000

    batches = []

    for i in range(
        0,
        len(rows),
        batch_size
    ):

        batch = rows[
            i:i + batch_size
        ]

        batches.append(batch)

    print(
        f"数据总量：{len(rows)}"
    )

    print(
        f"批次数量：{len(batches)}"
    )

    # ========================================================
    # 并发处理
    # ========================================================

    max_workers = 6

    print(
        f"并发进程数：{max_workers}"
    )

    all_results = []

    with ProcessPoolExecutor(
        max_workers=max_workers
    ) as executor:

        results = executor.map(
            process_batch,
            batches
        )

        for result in results:

            all_results.extend(result)

            print(
                f"当前已计算：{len(all_results)} 条"
            )

    print(
        f"坐标转换完成：{len(all_results)} 条"
    )

    # ========================================================
    # 批量更新数据库
    # ========================================================

    update_database(
        all_results
    )

    print("=" * 60)
    print("全部处理完成")
    print("=" * 60)


if __name__ == "__main__":

    main()

九、为什么这里使用 5000 条作为一个批次？

代码中：

batch_size = 5000

假设有：

100000 条数据

那么会被拆成：

总共：

20 个任务

然后交给：

ProcessPoolExecutor(max_workers=6)

处理。

实际效果类似：

批次1 ──→ 进程1
批次2 ──→ 进程2
批次3 ──→ 进程3
批次4 ──→ 进程4
批次5 ──→ 进程5
批次6 ──→ 进程6

批次7 ──→ 空闲进程
批次8 ──→ 空闲进程
...

十、为什么不建议一次创建几十万个任务？

例如：

executor.submit(
    gcj02_to_bd09,
    lng,
    lat
)

然后创建：

1000000 个 Future

这种方式会增加：

Python 内存占用
Future 对象数量
进程通信开销
调度开销

因此更适合：

批量提交任务，而不是一条数据一个任务。

十一、六并发应该如何设置？

如果机器 CPU 比较强，可以：

max_workers = 6

例如：

6 个 CPU 工作进程

如果服务器是：

8 核

可以测试：

max_workers = 6

或者：

max_workers = 8

但是并不是进程越多越快。

例如：

4进程 → 100秒
6进程 → 75秒
8进程 → 72秒
12进程 → 78秒

可能出现这种情况。

原因是进程之间存在：

CPU 调度
进程通信
内存
数据库

等额外开销。

因此建议实际测试。

十二、更加重要：支持断点续跑

实际生产环境中，数据量比较大的时候，程序不一定一次就能跑完。

例如：

总数据：4,700,000

第一次：
处理 1,500,000
程序异常退出

第二次：
继续处理剩余数据

这时候：

WHERE baidu_longitude IS NULL
  AND baidu_latitude IS NULL

就非常重要。

因为已经处理完成的数据：

baidu_longitude IS NOT NULL
baidu_latitude IS NOT NULL

下一次不会再次处理。

也就是说：

第一次运行

100万
 ↓
转换
 ↓
写入百度坐标


第二次运行

查询百度坐标为空的数据
 ↓
继续处理

这实际上就是一种非常简单的：

断点续跑机制。

十三、处理过程中程序中断怎么办？

假设：

总数据：1,000,000

程序运行到：

600,000

突然：

电脑重启
网络断开
程序异常

如果前面的数据已经提交到数据库：

baidu_longitude
baidu_latitude

已经存在。

重新运行：

WHERE baidu_longitude IS NULL
  AND baidu_latitude IS NULL

那么只会获取剩余数据。

例如：

第一次

1,000,000
 ↓
600,000 已完成


第二次

400,000
 ↓
继续处理

因此不需要重新计算全部数据。

十四、不要把所有结果一直放在内存中

上面的示例为了方便理解：

all_results = []

然后把所有结果放到内存。

如果只有：

4万条
10万条
几十万条

问题一般不大。

但是如果是：

500万
1000万

就不建议这样做。

更加适合：

读取一批
 ↓
并发计算
 ↓
立即写数据库
 ↓
释放内存
 ↓
读取下一批

也就是：

MySQL
 ↓
50000
 ↓
并发计算
 ↓
UPDATE
 ↓
50000
 ↓
并发计算
 ↓
UPDATE

这样内存更加稳定。

十五、百万级数据推荐的架构

如果数据量达到百万级甚至千万级，可以进一步改成：

                  MySQL
                    │
                    ↓
              分批读取 50000
                    │
                    ↓
        ┌─────────────────────┐
        │  ProcessPoolExecutor│
        │                     │
        │ P1  P2  P3  P4     │
        │ P5  P6              │
        └─────────────────────┘
                    │
                    ↓
              转换结果
                    │
                    ↓
             executemany()
                    │
                    ↓
                  MySQL
                    │
                    ↓
              下一批数据

这样不会因为一次加载全部数据导致内存暴涨。

十六、一个非常重要的问题：坐标系必须一致

做空间计算时，这一点非常重要。

例如：

市场区域边界
    ↓
BD-09

零售户
    ↓
GCJ-02

那么不能直接：

Point(mapx, mapy)

然后和 BD-09 Polygon 判断。

因为两个坐标系不是同一个坐标系。

正确方式应该是：

零售户 GCJ-02
      │
      ↓
GCJ-02 → BD-09
      │
      ↓
零售户 BD-09
      │
      ↓
与市场区域 BD-09 Polygon 计算

例如：

bd_lng, bd_lat = gcj02_to_bd09(
    mapx,
    mapy
)

point = Point(
    bd_lng,
    bd_lat
)

然后再进行：

polygon.covers(point)

十七、为什么推荐 `covers()` 而不是 `contains()`？

如果进行市场区域空间匹配：

polygon.contains(point)

有一个问题。

如果零售户刚好位于：

Polygon 边界线上

那么：

contains()

可能返回：

False

而：

polygon.covers(point)

会把边界上的点也计算进去。

对于“一个零售户属于哪个市场区域”这种业务：

polygon.covers(point)

通常更加符合业务需求。

十八、为什么需要注意边界点？

例如：

       A────────B
      /          \
     /            \
    C      ●       D
     \            /
      \          /
       E────────F

如果：

● = 零售户

那么可以判断：

polygon.covers(point)

如果零售户刚好落在：

A-B

这条边界线上，也可以统计到该区域。

十九、后续可以进一步使用 STRtree 加速

如果不仅需要坐标转换，还需要：

市场区域 Polygon
+
几十万个零售户

进行空间匹配。

不要让每个零售户遍历全部 Polygon：

for customer in customers:

    for polygon in polygons:

        if polygon.covers(customer):
            ...

假设：

100000 个零售户
10000 个区域

理论上可能产生：

100000 × 10000
=
10亿次判断

这会非常慢。

可以使用 Shapely 的：

STRtree

建立空间索引：

from shapely.strtree import STRtree

tree = STRtree(polygons)

然后：

candidate_indexes = tree.query(point)

先找出空间上可能相交的 Polygon，再进行：

polygon.covers(point)

这样可以显著减少实际判断次数。

二十、一个完整的数据处理架构

最终可以形成：

                MySQL
                  │
        ┌─────────┴─────────┐
        │                   │
        ↓                   ↓
  零售户坐标             区域边界
  GCJ-02                  BD-09
        │                   │
        ↓                   │
 GCJ-02 → BD-09             │
        │                   │
        ↓                   ↓
   BD-09 Point        BD-09 Polygon
        │                   │
        └─────────┬─────────┘
                  ↓
              STRtree
                  │
                  ↓
            空间匹配
                  │
                  ↓
          统计每个区域户数
                  │
                  ↓
       t_comm_area_info.now_num

二十一、生产环境建议

如果数据量比较大，建议遵循以下原则。

1. 不要一次读取全部数据

使用：

5000
10000
50000

等批次。

2. 并发数不要盲目提高

例如：

max_workers = 6

先测试。

根据 CPU、内存和实际耗时再调整。

3. 数据库更新使用 executemany

不要：

UPDATE
UPDATE
UPDATE
UPDATE

而是：

cursor.executemany(
    sql,
    results
)

减少数据库交互。

4. 增加断点续跑条件

例如：

WHERE baidu_longitude IS NULL
  AND baidu_latitude IS NULL

5. 转换结果建议使用 DOUBLE

不要使用：

FLOAT

保存高精度经纬度时建议：

DOUBLE

例如：

baidu_longitude DOUBLE DEFAULT NULL,
baidu_latitude DOUBLE DEFAULT NULL

二十二、最终效果

经过优化以后，整体处理流程从：

查询一条
 ↓
转换一条
 ↓
更新一条
 ↓
查询一条
 ↓
转换一条
 ↓
更新一条

优化成：

批量查询
    ↓
    ↓
┌───────────────┐
│ 6进程并发计算 │
└───────────────┘
    ↓
批量结果
    ↓
executemany
    ↓
MySQL
    ↓
下一批

核心优化点可以总结为：

优化方式	作用
批量查询	减少数据库交互
多进程	提高 CPU 利用率
批量计算	减少进程调度开销
executemany	减少 UPDATE 次数
NULL 判断	支持断点续跑
DOUBLE	保存更高精度
GCJ-02 → BD-09	保证坐标系一致
STRtree	加速大量空间匹配
`covers()`	将边界上的点纳入统计

对于几十万到几百万条坐标数据，这种方式比单条查询、单条计算、单条 UPDATE 更适合实际的数据处理任务。

总结

高德坐标转换成百度坐标，本身并不复杂，真正影响大数据处理效率的主要是：

数据库读取方式
        +
任务拆分方式
        +
并发模型
        +
数据库写入方式
        +
断点续跑

因此推荐采用：

MySQL
  ↓
批量读取
  ↓
ProcessPoolExecutor
  ↓
6进程并发
  ↓
GCJ-02 → BD-09
  ↓
批量 UPDATE
  ↓
继续下一批

如果后续还需要将转换后的百度坐标用于市场网格、村级区域、许可证布局等空间区域匹配，可以继续结合 Shapely + STRtree，实现：

零售户坐标
    ↓
百度坐标
    ↓
判断所在区域 Polygon
    ↓
统计每个村/网格零售户数量
    ↓
更新 t_comm_area_info.now_num

这样就可以从单纯的“坐标转换程序”，进一步扩展成完整的零售户空间数据治理和市场网格分析程序。

DolphinScheduler 3.2.2 集成 SeaTunnel 任务启动失败问题排查与解决方案

Tue, 29 Sep 2026 09:07:57 +0800

一、问题背景

在使用 Apache DolphinScheduler 3.2.2 调度 SeaTunnel 数据同步任务时，发现任务在 DolphinScheduler 中执行失败。

SeaTunnel 本身安装正常，手动在服务器上执行 SeaTunnel 命令也能够正常运行，但是通过 DolphinScheduler 的：

bash ./bin/start-all.sh

启动集群后，再执行 SeaTunnel 任务会出现以下错误：

18_132.sh: 行 4: /bin/seatunnel.sh: 没有那个文件或目录

经过排查发现：

手动启动 Worker 时，SeaTunnel 任务可以正常执行；
使用 start-all.sh 启动 DolphinScheduler 后，SeaTunnel 任务执行失败；
SeaTunnel 安装目录实际存在；
DolphinScheduler Worker 的 SEATUNNEL_HOME 环境变量在不同启动方式下存在差异。

最终定位到问题根因：

DolphinScheduler 的 dolphinscheduler-daemon.sh 在启动 Worker 时，会使用 bin/env/dolphinscheduler_env.sh 覆盖 Worker 自己的 conf/dolphinscheduler_env.sh。

因此，仅修改：

worker-server/conf/dolphinscheduler_env.sh

并不能保证通过 start-all.sh 启动后仍然生效。

二、环境信息

本次环境主要信息如下：

项目	配置
DolphinScheduler	3.2.2
SeaTunnel	本地部署
操作系统	Linux / Ubuntu
Java	OpenJDK 17
DolphinScheduler目录	`/usr/local/server/dolphinscheduler`
SeaTunnel目录	`/usr/local/server/seatunnel`
Worker目录	`/usr/local/server/dolphinscheduler/worker-server`
Worker端口	`1234`

SeaTunnel 实际安装位置：

/usr/local/server/seatunnel

正常情况下需要：

SEATUNNEL_HOME=/usr/local/server/seatunnel

这样 DolphinScheduler 执行 SeaTunnel 时：

${SEATUNNEL_HOME}/bin/seatunnel.sh

才能正确解析为：

/usr/local/server/seatunnel/bin/seatunnel.sh

三、故障现象

DolphinScheduler 执行 SeaTunnel 任务时，日志出现：

18_132.sh: 行 4: /bin/seatunnel.sh: 没有那个文件或目录

从任务执行命令来看：

${SEATUNNEL_HOME}/bin/seatunnel.sh \
    --config /tmp/dolphinscheduler/exec/process/default/185039101090048/185039137408256_2/18/132/seatunnel_18_132.conf \
    --deploy-mode cluster

正常情况下：

${SEATUNNEL_HOME}
        ↓
/usr/local/server/seatunnel
        ↓
/usr/local/server/seatunnel/bin/seatunnel.sh

但是实际错误变成：

${SEATUNNEL_HOME}
        ↓
空
        ↓
/bin/seatunnel.sh

因此可以初步判断：

问题不是 SeaTunnel 的 seatunnel.sh 不存在，而是 DolphinScheduler Worker 执行任务时没有获得 SEATUNNEL_HOME。

四、首先确认 SeaTunnel 本身是否正常

先检查 SeaTunnel：

ls -l /usr/local/server/seatunnel/bin/seatunnel.sh

如果能够看到：

/usr/local/server/seatunnel/bin/seatunnel.sh

说明 SeaTunnel 文件本身存在。

然后测试：

/usr/local/server/seatunnel/bin/seatunnel.sh --help

如果能够正常输出 SeaTunnel 帮助信息，则说明：

SeaTunnel 安装正常；
Java 基础环境基本正常；
seatunnel.sh 本身可以执行。

进一步测试环境变量：

export SEATUNNEL_HOME=/usr/local/server/seatunnel

$SEATUNNEL_HOME/bin/seatunnel.sh --help

如果正常，则进一步证明问题集中在：

DolphinScheduler Worker → 环境变量

而不是 SeaTunnel 本身。

五、第一次排查：修改 Worker 环境文件

DolphinScheduler Worker 使用：

/usr/local/server/dolphinscheduler/worker-server/conf/dolphinscheduler_env.sh

因此最初的解决方法是在该文件中增加：

export SEATUNNEL_HOME=/usr/local/server/seatunnel

检查：

grep -n "SEATUNNEL_HOME" \
/usr/local/server/dolphinscheduler/worker-server/conf/dolphinscheduler_env.sh

如果存在：

export SEATUNNEL_HOME=/usr/local/server/seatunnel

再手动执行 Worker：

/usr/local/server/dolphinscheduler/worker-server/bin/start.sh

此时 SeaTunnel 任务可以正常运行。

这说明：

worker-server/conf/dolphinscheduler_env.sh 中增加 SEATUNNEL_HOME 是有效的。

但是问题并没有彻底解决。

六、为什么手动启动可以，start-all.sh 却不行？

这是本次问题最关键的地方。

手动启动：

/usr/local/server/dolphinscheduler/worker-server/bin/start.sh

与：

bash ./bin/start-all.sh

实际上不是完全相同的启动路径。

6.1 手动启动路径

手动启动大致为：

worker-server/bin/start.sh
        ↓
读取
worker-server/conf/dolphinscheduler_env.sh
        ↓
读取 SEATUNNEL_HOME
        ↓
启动 Worker

因此手动启动时：

export SEATUNNEL_HOME=/usr/local/server/seatunnel

能够正常生效。

七、start-all.sh 的实际启动流程

检查：

/usr/local/server/dolphinscheduler/bin/start-all.sh

可以发现 Worker 并不是直接调用：

worker-server/bin/start.sh

而是：

bash bin/dolphinscheduler-daemon.sh start worker-server

也就是说：

start-all.sh
    ↓
dolphinscheduler-daemon.sh
    ↓
worker-server/bin/start.sh

真正关键的是中间这一层：

dolphinscheduler-daemon.sh

八、发现真正的根因：环境文件会被覆盖

查看：

cat /usr/local/server/dolphinscheduler/bin/dolphinscheduler-daemon.sh

其中存在：

function overwrite_server_env() {
  local server=$1
  local server_env_file="${DOLPHINSCHEDULER_HOME}/${server}/conf/dolphinscheduler_env.sh"

  if [ -f "${BIN_ENV_FILE}" ]; then
    echo "Overwrite ${server}/conf/dolphinscheduler_env.sh using bin/env/dolphinscheduler_env.sh."
    cp "${BIN_ENV_FILE}" "${server_env_file}"
  else
    echo "Start server ${server} using env config path ${server_env_file}, because file ${BIN_ENV_FILE} not exists."
  fi
}

其中：

BIN_ENV_FILE="${DOLPHINSCHEDULER_HOME}/bin/env/dolphinscheduler_env.sh"

而 Worker 启动时执行：

overwrite_server_env "${command}"

因此实际发生的是：

/usr/local/server/dolphinscheduler/bin/env/dolphinscheduler_env.sh
                ↓
                ↓ cp
                ↓
/usr/local/server/dolphinscheduler/worker-server/conf/dolphinscheduler_env.sh

也就是说：

worker-server/conf/dolphinscheduler_env.sh 并不是最终的配置源。

它会在 DolphinScheduler 使用 dolphinscheduler-daemon.sh 启动 Worker 时被覆盖。

九、完整问题链路

整个问题可以表示为：

                    DolphinScheduler
                           │
                           ▼
                    start-all.sh
                           │
                           ▼
              dolphinscheduler-daemon.sh
                           │
                           ▼
                 overwrite_server_env()
                           │
                           │
              ┌────────────┴────────────┐
              │                         │
              ▼                         ▼
bin/env/dolphinscheduler_env.sh    worker-server/conf/
                                  dolphinscheduler_env.sh
              │                         ▲
              │                         │
              └────────── cp ──────────┘
                                        │
                                        ▼
                              worker-server/bin/start.sh
                                        │
                                        ▼
                              读取 dolphinscheduler_env.sh
                                        │
                                        ▼
                              SEATUNNEL_HOME 是否存在？
                                        │
                         ┌──────────────┴──────────────┐
                         │                             │
                        是                             否
                         │                             │
                         ▼                             ▼
              /usr/local/server/             ${SEATUNNEL_HOME}
                  seatunnel                  为空
                         │                             │
                         ▼                             ▼
           /usr/local/server/seatunnel/       /bin/seatunnel.sh
               bin/seatunnel.sh                     │
                                                     ▼
                                                  ❌ 失败

十、正确解决方案

10.1 不应该只修改 Worker 配置文件

之前修改：

/usr/local/server/dolphinscheduler/worker-server/conf/dolphinscheduler_env.sh

虽然可以让手动启动生效，但是：

start-all.sh

启动时会重新覆盖该文件。

因此不推荐只修改这里。

10.2 修改统一环境配置

正确配置文件应该是：

/usr/local/server/dolphinscheduler/bin/env/dolphinscheduler_env.sh

首先检查：

grep -n "SEATUNNEL_HOME" \
/usr/local/server/dolphinscheduler/bin/env/dolphinscheduler_env.sh

如果没有结果，则增加：

echo 'export SEATUNNEL_HOME=/usr/local/server/seatunnel' >> \
/usr/local/server/dolphinscheduler/bin/env/dolphinscheduler_env.sh

然后确认：

tail -n 10 \
/usr/local/server/dolphinscheduler/bin/env/dolphinscheduler_env.sh

应该能够看到：

export SEATUNNEL_HOME=/usr/local/server/seatunnel

十一、重新启动 DolphinScheduler

修改统一配置之后，需要重新启动服务。

进入：

cd /usr/local/server/dolphinscheduler

停止：

bash ./bin/stop-all.sh

检查 Worker：

ps -ef | grep WorkerServer | grep -v grep

确认旧 Worker 已经停止后，再执行：

bash ./bin/start-all.sh

十二、验证配置是否被正确复制

启动完成以后，首先检查：

grep -n "SEATUNNEL_HOME" \
/usr/local/server/dolphinscheduler/worker-server/conf/dolphinscheduler_env.sh

应该看到：

export SEATUNNEL_HOME=/usr/local/server/seatunnel

这是因为：

bin/env/dolphinscheduler_env.sh
        ↓
dolphinscheduler-daemon.sh
        ↓
overwrite_server_env()
        ↓
worker-server/conf/dolphinscheduler_env.sh

已经完成了正确的配置复制。

十三、进一步检查 Worker 进程环境

仅检查配置文件还不够，最好检查实际运行中的 Worker JVM 环境。

先找到 Worker PID：

ps -ef | grep WorkerServer | grep -v grep

例如得到：

dolphin+ 153245 ... org.apache.dolphinscheduler.server.worker.WorkerServer

然后：

PID=153245

cat /proc/$PID/environ | tr '\0' '\n' | \
grep -E 'SEATUNNEL_HOME|DOLPHINSCHEDULER_HOME|JAVA_HOME'

正常应该至少包含：

SEATUNNEL_HOME=/usr/local/server/seatunnel

这样才能证明：

SEATUNNEL_HOME 不仅写入了配置文件，而且真正进入了 Worker 进程环境。

十四、最终验证 SeaTunnel 任务

重新执行 DolphinScheduler 中的 SeaTunnel 任务。

任务命令：

${SEATUNNEL_HOME}/bin/seatunnel.sh \
--config /tmp/dolphinscheduler/exec/process/default/.../seatunnel_18_132.conf \
--deploy-mode cluster

此时应该被正确解析为：

/usr/local/server/seatunnel/bin/seatunnel.sh \
--config /tmp/dolphinscheduler/exec/process/default/.../seatunnel_18_132.conf \
--deploy-mode cluster

不再出现：

/bin/seatunnel.sh: 没有那个文件或目录

十五、建议增加一项启动检查

为了以后避免类似问题，可以在部署完成后执行：

echo "===== DolphinScheduler Environment ====="

echo "DOLPHINSCHEDULER_HOME=$DOLPHINSCHEDULER_HOME"
echo "SEATUNNEL_HOME=$SEATUNNEL_HOME"
echo "JAVA_HOME=$JAVA_HOME"

echo "===== SeaTunnel ====="

ls -l "$SEATUNNEL_HOME/bin/seatunnel.sh"

如果：

SEATUNNEL_HOME=

或者：

ls: cannot access .../seatunnel.sh

就不要继续执行任务，应先修复环境变量。

十六、另一个独立问题：Java 17 的 InaccessibleObjectException

在排查过程中还发现了另外一个异常：

java.lang.reflect.InaccessibleObjectException:
Unable to make field private final int java.lang.ProcessImpl.pid accessible:
module java.base does not "opens java.lang" to unnamed module

这个问题与：

/bin/seatunnel.sh: 没有那个文件或目录

不是同一个问题。

前者属于：

DolphinScheduler
        ↓
Java 17
        ↓
反射访问 JDK 内部字段
        ↓
Java Module System
        ↓
InaccessibleObjectException

后者属于：

DolphinScheduler Worker
        ↓
SEATUNNEL_HOME
        ↓
环境变量没有传递
        ↓
/bin/seatunnel.sh

因此排查时应该分开处理。

十七、Java 17 问题的处理方向

当前 Worker 使用：

Java 17

而 DolphinScheduler 相关代码中存在：

java.lang.ProcessImpl.pid

等反射访问。

后续可以检查 Worker 的：

/usr/local/server/dolphinscheduler/worker-server/bin/jvm_args_env.sh

以及实际启动参数：

ps -ef | grep WorkerServer | grep -v grep

重点确认是否需要增加类似：

--add-opens=java.base/java.lang=ALL-UNNAMED

对于另外出现的：

java.lang.invoke.SerializedLambda.capturingClass

则可能涉及：

--add-opens=java.base/java.lang.invoke=ALL-UNNAMED

不过这属于第二阶段问题。

建议先确认 SeaTunnel 调度链路恢复正常，再单独处理 Java 17 反射兼容问题。

十八、排查过程中最容易犯的错误

错误一：只修改 worker-server 配置

例如：

vim /usr/local/server/dolphinscheduler/worker-server/conf/dolphinscheduler_env.sh

增加：

export SEATUNNEL_HOME=/usr/local/server/seatunnel

然后认为问题已经解决。

实际上：

start-all.sh
    ↓
dolphinscheduler-daemon.sh
    ↓
overwrite_server_env()

会覆盖这个文件。

错误二：只测试手动启动

worker-server/bin/start.sh

正常并不代表：

start-all.sh

正常。

因为两种启动路径不同。

因此排查 DolphinScheduler 服务环境问题时，应优先验证实际生产启动方式。

错误三：看到 `/bin/seatunnel.sh` 就认为 SeaTunnel 没安装

实际上：

/bin/seatunnel.sh

这个路径本身就暴露了问题。

如果正确配置：

SEATUNNEL_HOME=/usr/local/server/seatunnel

最终路径应该是：

/usr/local/server/seatunnel/bin/seatunnel.sh

因此：

/bin/seatunnel.sh

实际上说明：

${SEATUNNEL_HOME} 没有展开出有效值。

十九、推荐的最终配置结构

建议把 DolphinScheduler 与 SeaTunnel 的环境配置统一管理：

/usr/local/server/dolphinscheduler/
│
├── bin/
│   ├── start-all.sh
│   ├── stop-all.sh
│   ├── dolphinscheduler-daemon.sh
│   │
│   └── env/
│       └── dolphinscheduler_env.sh    ← ★统一配置源
│
├── worker-server/
│   ├── bin/
│   │   └── start.sh
│   │
│   └── conf/
│       └── dolphinscheduler_env.sh    ← daemon启动时覆盖
│
└── ...

统一配置：

# SeaTunnel
export SEATUNNEL_HOME=/usr/local/server/seatunnel

这样：

start-all.sh
       ↓
dolphinscheduler-daemon.sh
       ↓
bin/env/dolphinscheduler_env.sh
       ↓
worker-server/conf/dolphinscheduler_env.sh
       ↓
worker-server/bin/start.sh
       ↓
Worker JVM
       ↓
SeaTunnel Task

整个链路的环境变量才能保持一致。

二十、总结

本次问题最终可以归纳为：

表面错误

/bin/seatunnel.sh: 没有那个文件或目录

直接原因

SEATUNNEL_HOME 为空

深层原因

通过：

start-all.sh

启动 DolphinScheduler 时：

dolphinscheduler-daemon.sh

会执行：

overwrite_server_env "${command}"

将：

bin/env/dolphinscheduler_env.sh

复制覆盖：

worker-server/conf/dolphinscheduler_env.sh

而 SEATUNNEL_HOME 之前只配置在 Worker 自己的配置文件中，所以被覆盖后丢失。

正确解决方案

将：

export SEATUNNEL_HOME=/usr/local/server/seatunnel

配置到：

/usr/local/server/dolphinscheduler/bin/env/dolphinscheduler_env.sh

然后重新执行：

cd /usr/local/server/dolphinscheduler

bash ./bin/stop-all.sh

bash ./bin/start-all.sh

最后验证：

grep -n "SEATUNNEL_HOME" \
/usr/local/server/dolphinscheduler/worker-server/conf/dolphinscheduler_env.sh

以及：

PID=$(pgrep -f 'org.apache.dolphinscheduler.server.worker.WorkerServer' | head -1)

cat /proc/$PID/environ | tr '\0' '\n' | \
grep SEATUNNEL_HOME

预期：

SEATUNNEL_HOME=/usr/local/server/seatunnel

核心经验：在 DolphinScheduler 中，通过 start-all.sh 启动服务时，应优先修改 bin/env/ 下的统一环境配置，而不是只修改各 Server 自己的 conf/ 环境文件。

Windows 精确触摸板实现 Mac 同款三指拖拽完整教程

Wed, 26 Aug 2026 10:09:55 +0800

很多用惯 Mac 的用户换到 Windows 笔记本后，最不习惯的就是触摸板缺少三指拖移——三根手指轻放触控板直接拖动窗口、框选文字、拖拽文件，不用用力按压触摸板。本文使用开源免费工具 ThreeFingerDragOnWindows，仅适用于 Windows Precision 精确触摸板（PTP），老款 Synaptics/ELAN 非PTP触控板不支持该方案。

一、前置检查：确认你的电脑是否支持

1. 检测精确触摸板

按下快捷键 Win + I 打开设置 → 蓝牙和设备 → 触摸板页面顶部出现文字：你的电脑有一个精确式触摸板，才可以继续。

如果没有该提示，代表是老旧触控板，底层不支持PTP手势，本方案无效。

2. 确认系统架构（选择对应安装包）

任务栏右键打开任务管理器 → 性能 → CPU

普通AMD/Intel处理器（如R5 4600U、i5-1135G7等）→ x64
Surface Pro X、国产ARM笔记本 → arm64
古董32位系统 → x86

绝大多数新款笔记本直接选择 x64 版本。

二、准备工作：关闭系统原生三指手势（关键！防止冲突）

同样在 Win+I → 蓝牙和设备 → 触摸板

找到三指手势，将三指上滑、下滑、左右滑动全部设置为无
点击选项里，取消勾选【点击两次并拖动以多选】，该选项极易造成误触
✅ 四指手势不受影响，可以保留「四指左右切换虚拟桌面」等原生功能

三、下载与安装 ThreeFingerDragOnWindows

方式1：GitHub 离线安装包（推荐，无网络商店限制）

项目开源地址：https://github.com/ClementGre/ThreeFingerDragOnWindows在 Releases → Assets 里选择对应架构文件：

x64架构：ThreeFingersDragOnWindows_2.0.7_x64.Msix（绝大多数用户）
arm64架构：ThreeFingersDragOnWindows_2.0.7_arm64.Msix
x86(32位)：ThreeFingersDragOnWindows_2.0.7_x86.Msix

.msix 是微软官方安装包，双击即可安装；如果提示安装策略拦截：右键文件 → 属性 → 勾选【解除锁定】后重试。

方式2：微软商店一键安装（最简单，自动更新）

直接打开微软商店，搜索 ThreeFingerDragOnWindows，一键安装，和离线包内容完全一致。

四、软件基础配置（安装完成后打开软件设置）

打开 ThreeFingerDragOnWindows，按照下面参数配置：

✅ Enable three finger drag：开启三指拖拽总开关
Mouse button to be held while dragging：选择 Left button（模拟左键拖拽）
Delay before drag starts（触发延迟）：推荐 200~500ms，数值越高越不容易误触
✅ Run on startup：勾选开机自启
✅ Elevated mode（管理员模式）：勾选后可以拖动任务管理器、安装弹窗这类管理员权限窗口（强烈建议开启）
查看检测状态：显示绿色文字 Touchpad exists and is registered! = 触摸板识别成功
拖拽灵敏度、鼠标加速默认即可，新手无需额外调整

五、使用方法（和Mac完全一致）

三根手指同时轻放在触摸板上直接滑动：

拖动窗口位置
鼠标框选文字、选中文件
拖拽文件、调整选区抬起任意一根手指，拖拽动作立刻结束

六、常见故障排查

三根手指放上去没有任何反应

确认是Precision精确触摸板
系统三指手势已经全部设置为【无】
软件检测提示成功识别触摸板，必要时开启管理员模式

频繁误触，随便放三根手指就触发拖拽

调高触发延迟（调到400~500ms），降低拖拽灵敏度

普通窗口可以拖动，任务管理器/安装弹窗拖不动

在软件设置里开启 Elevated mode，重启软件生效

msix安装包无法安装

优先改用微软商店直接安装

七、拓展方案（可选，丰富更多Mac手势）

ThreeFingerDragOnWindows只专注实现三指拖移，如果你想要更多自定义手势（四指收拢打开开始菜单、媒体控制等），可以搭配下面工具：

GestureSign：免费可视化手势自定义工具，功能丰富，适合需要大量自定义手势的用户
AutoHotkey：脚本级自定义，自由度天花板，适合有基础的进阶玩家
外接妙控板Magic Trackpad：搭配开源驱动，可以实现无限接近原生Mac触摸板完整体验

八、局限说明（硬件底层限制，无法完美复刻Mac）

普通Windows触摸板没有Force Touch压力感应、线性马达触觉反馈，无法实现按压预览、力度反馈
Windows底层滚动惯性算法和macOS不同，即便全部设置完成，顺滑度依然存在细微差距
老旧Win32软件对手势支持不一致，部分程序会吞掉触摸板手势，识别稳定性不如Mac全局统一

补充：原生触摸板基础Mac风格配置（搭配三指拖移一起用）

在系统触摸板设置中额外开启：

✅ 轻点来点按（单指轻触=左键，不用按下去）
✅ 双指轻点=右键
✅ 自然滚动（滚动方向和Mac保持一致）
✅ 双指捏合缩放、双指左右滑动网页前进后退
✅ 四指左右滑动切换虚拟桌面

NyaTerm 最近发现的一款好用的运维工具分享

Mon, 10 Aug 2026 10:07:50 +0800

NyaTerm 是国产的免费开源、跨平台现代化一站式终端运维客户端，对标 Xshell、MobaXterm、WindTerm，由 Rust+Tauri+React 开发，全平台无付费阉割功能，主打一套软件搞定服务器远程登录、文件传输、设备调试、服务器监控等全流程运维工作。

1. 支持连接协议

协议类型	适用场景
SSH（核心）	Linux 服务器远程登录、跳板机、端口转发、OTP 二次验证
内置 SFTP	服务器文件上传下载，无需单独装 WinSCP
本地 Shell	Windows CMD/PowerShell、macOS/Linux 原生终端
Telnet	老旧交换机、工业老旧设备调试
Serial 串口	嵌入式开发板、网络交换机 Console 调试

2. 核心特色功能

多标签、横竖分屏，单界面同时管理多台服务器；
侧边一键查看服务器 CPU / 内存 / 磁盘 / GPU 实时监控、Docker 可视化管理；
内置 AI 终端助手：选中报错自动解析、自然语言生成运维命令；
一键导入 Xshell、MobaXterm、WindTerm 旧会话配置；
连接配置本地加密、云同步备份；
终端操作录制回放、快捷命令模板、SSH 隧道内网穿透。

下载地址

官网：https://nyaterm.app

GitHub 发行页：https://github.com/nyakang/nyaterm/releases

界面

显卡进程查看

硬件资源查看

docker管理

AI集成

windows端口转发，可转发WSL端口

Mon, 27 Jul 2026 15:48:06 +0800

windows自带有端口转发命令，没必要安装其他管理软件

命令如下，将8003端口转发到WSL中的 8003 端口

netsh interface portproxy add v4tov4 listenport=8003 listenaddress=0.0.0.0 connectport=8003 connectaddress=127.0.0.1

查看全部的已配置的转发端口

netsh interface portproxy show all

有个服务必须启动

服务启动后执行以下命令设置开机启动

:: 立即启动 IP Helper 服务
sc start iphlpsvc

:: 设置服务开机自动启动（注意 start= 后面有空格，语法硬性要求）
sc config iphlpsvc start= auto

windwos和linux下获取当前使用的麦克风型号

Fri, 24 Jul 2026 14:17:39 +0800

需求是浏览器获取当前麦克风型号，对不支持的型号做限制，

最开始想的通过js后去麦克风型号，但是在windows下测试的没问题，到linux系统下就不行了

历览器输入以下地址可以看到支持的硬件信息

chrome://media-internals/

在windows下可以看到支持的型号，

但是在linux下看不到

windwo下需要使用 sounddevice 库，linux下使用 pulsectl

import sys

def get_windows_active_mic():
    """Windows 系统：通过 COM/pycaw 接口精确获取当前默认输入的麦克风型号"""
    import sounddevice as sd

    devices = sd.query_devices()

    default_in_id = sd.default.device[0]
    # print("默认录音设备ID：", default_in_id)
    # print("默认录音设备ID：", devices[default_in_id])
    
    return devices[default_in_id]['name']

def get_active_mic_pulsectl():
    import pulsectl
    try:
        with pulsectl.Pulse('get-mic-script') as pulse:
            # 1. 获取默认 Source 的名称
            server_info = pulse.server_info()
            default_source_name = server_info.default_source_name

            # 2. 遍历 Source 寻找描述信息
            for source in pulse.source_list():
                if source.name == default_source_name:
                    # 获取 friendly 名称
                    desc = source.proplist.get('device.description') or source.description
                    return desc
        return "未找到设备"
    except Exception as e:
        return f"获取失败: {e}"

def get_active_mic():
    print(sys.platform)
    """根据操作系统自动路由"""
    if sys.platform.startswith("win"):
        return get_windows_active_mic()
    elif sys.platform.startswith("linux"):
        return get_active_mic_pulsectl()
    else:
        return f"暂不支持的操作系统: {sys.platform}"

if __name__ == "__main__":
    print("当前正在使用的麦克风型号:", get_active_mic())

VLLM服务端启动ChineseErrorCorrector3-4B模型

Sun, 12 Jul 2026 21:46:23 +0800

先贴命令

vllm serve /www/models/Qwen/ChineseErrorCorrector3-4B \
    --max-model-len 10240 \
    --dtype float16 \
    --max-num-batched-tokens 10240 \
    --gpu-memory-utilization 0.4 \
    --max-num-seqs 512 \
    --host 0.0.0.0 \
    --port 8004 \
    --served-model-name csc-3B

这条命令的作用：用 vLLM 高性能推理框架，把中文纠错模型 ChineseErrorCorrector3-4B 启动成兼容 OpenAI 接口格式的 HTTP 推理服务，外部程序可通过 8004 端口调用文本纠错能力。

vllm servevLLM 提供的服务启动子命令，自动内置 OpenAI 兼容 REST API（/v1/completions、/v1/chat/completions），无需自己封装接口。

/www/models/Qwen/ChineseErrorCorrector3-4B本地模型权重文件路径，指向 4B 参数中文文本纠错模型（CSC 错别字校对模型）。

--max-model-len 10240

模型最大支持输入 + 输出总 token 长度 10240。

适合长文本纠错场景（长篇文档、案卷、文章批量校对），超过长度会截断输入。

--dtype float16模型权重 / 推理计算使用 FP16 半精度：

显存占用减半，相比 FP32 节省大量显存；速度更快，绝大多数 Nvidia GPU 原生支持 FP16 加速；纠错类模型对精度不敏感，FP16 不会明显降低校对准确率。

--max-num-batched-tokens 10240

单次推理批处理中，所有并发请求的 token 总和上限 10240。

用来防止瞬间大量长文本请求撑爆显存，和 max-model-len 配套管控显存负载。

--gpu-memory-utilization 0.4限制模型 + KV 缓存最多占用40% GPU 显存（0.4 = 40%）。

预留 60% 显存给系统、其他进程、突发 KV 缓存；多模型混跑、显卡同时跑其他任务时常用低利用率；纯单模型独占显卡可调高至 0.8~0.95 提升并发。

--max-num-seqs 512服务同时允许最多 512 条并行推理序列（并发请求）。

短文本纠错场景可拉高，支持高 QPS；长文本场景建议降低，避免 KV 缓存暴涨 OOM。

--host 0.0.0.0监听本机所有网卡地址，允许局域网 / 其他服务器远程访问接口；若写 127.0.0.1 则仅本机可调用，外部无法连接。

--port 8004HTTP 服务监听端口，调用地址示例：http://服务器IP:8004/v1/chat/completions

--served-model-name csc-3B

API 请求时需要指定的 model 参数名称，不用填冗长模型路径。

调用示例请求体片段：

{
  "model": "csc-3B",
  "prompt": "需要纠错的原文"
}

windows右键管理

Wed, 27 May 2026 09:35:57 +0800

windows11设计之初是为了简化右键，但是很多功能都隐藏起来了，要不通过shift + 右键出来详细右键，要不就得点详情来看，通过以下方法可以直接换为旧版的右键菜单。

开始菜单搜索cmd，以管理员身份打开

运行以下命令

reg.exe add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}" /f
reg.exe add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve

再执行

taskkill /f /im explorer.exe
start explorer.exe

然后点右键就是旧版的菜单了。

还有一个好用的右键菜单管理工具推荐。

ContextMenuManager

下载链接

下载完后不需要安装直接打开就能用

可以管理文件、文件夹、目录等等各种右键菜单。

我现在在目录里面右键就只剩下这些了。

简化了很多。

星光下的赶路人

ossutil常用操作

一、版本查看

二、配置相关

v1

v2

三、列举 bucket / 列举桶内文件

四、上传文件/文件夹

五、下载文件/文件夹

六、桶之间互拷（同region，服务端复制，不落地本地）✅

七、同步 sync（镜像同步：源删了，目标也删除，谨慎！）

八、删除对象（慎用！）

九、创建 / 删除 bucket

十、获取文件元信息

十一、批量命令通用参数（v1、v2 大部分通用）

⚠️ 两个版本踩坑重点（非常关键）

OpenList 从入门到进阶：Windows 部署、网盘挂载与多用户分享全指南

一、OpenList 与 Alist：为什么选它？

二、Windows 部署：下载与启动

下载哪个版本？

启动服务

三、挂载国内网盘

阿里云盘（推荐 OAuth2 方式）

百度网盘

夸克网盘

四、文件分享

分享方式

Python 实现高德 GCJ-02 转百度 BD-09：MySQL 批量并发处理与断点续跑

一、问题背景

二、GCJ-02 和 BD-09 是什么？

WGS-84

GCJ-02

BD-09

三、GCJ-02 转 BD-09 算法

四、为什么不能直接逐条查询和更新？

1. 数据库交互次数太多

2. 单线程速度比较慢

五、优化思路

六、为什么使用多进程？

七、批量并发处理

八、完整代码

九、为什么这里使用 5000 条作为一个批次？

十、为什么不建议一次创建几十万个任务？

十一、六并发应该如何设置？

十二、更加重要：支持断点续跑

十三、处理过程中程序中断怎么办？

十四、不要把所有结果一直放在内存中

十五、百万级数据推荐的架构

十六、一个非常重要的问题：坐标系必须一致

十七、为什么推荐 covers() 而不是 contains()？

十八、为什么需要注意边界点？

十九、后续可以进一步使用 STRtree 加速

二十、一个完整的数据处理架构

二十一、生产环境建议

1. 不要一次读取全部数据

2. 并发数不要盲目提高

3. 数据库更新使用 executemany

4. 增加断点续跑条件

5. 转换结果建议使用 DOUBLE

二十二、最终效果

总结

DolphinScheduler 3.2.2 集成 SeaTunnel 任务启动失败问题排查与解决方案

一、问题背景

二、环境信息

三、故障现象

四、首先确认 SeaTunnel 本身是否正常

五、第一次排查：修改 Worker 环境文件

六、为什么手动启动可以，start-all.sh 却不行？

6.1 手动启动路径

七、start-all.sh 的实际启动流程

八、发现真正的根因：环境文件会被覆盖

九、完整问题链路

十、正确解决方案

10.1 不应该只修改 Worker 配置文件

10.2 修改统一环境配置

十一、重新启动 DolphinScheduler

十二、验证配置是否被正确复制

十三、进一步检查 Worker 进程环境

十四、最终验证 SeaTunnel 任务

十五、建议增加一项启动检查

十七、为什么推荐 `covers()` 而不是 `contains()`？

错误三：看到 `/bin/seatunnel.sh` 就认为 SeaTunnel 没安装