公司有一台内网服务器（btk-acloud，Ubuntu 24.04 LTS），上面 /data/baic_n60/ 目录里存着团队的共享文件。内部同事需要随时通过浏览器访问这些文件——浏览目录、下载。

这台机器有几个约束：

不允许在这个不带外网的机器上折腾 pip install、uv pip install、docker pull、或者 apt-get install nginx 拉一堆依赖——这台机器不是开发机，是生产服务器，不能为一个小需求破坏系统 Python 环境。

2 环境拓扑

[ 同事浏览器 ]
       │
       ↓ HTTP :19527
[ 112.31.22.151:3022 ]    ← 对外暴露的 SSH 端口（NAT 映射）
       ↑
[ 跳板机 10.10.0.4 ]      ← SSH 隧道中转
       ↑
[ 10.177.100.30 ]          ← 内网目标机（btk-acloud）
       │
       ↓
[ /data/baic_n60/ ]        ← 45.5TB 机械盘，实际数据 7.5TB

连接命令：

sshpass -p '<password>' ssh \
  -o "ProxyCommand ssh -i ~/.ssh/id_ed25519 herui@10.10.0.4 -W %h:%p" \
  -p 3022 sup1whu@112.31.22.151

由于内网同事通过 HTTP 请求直接打到目标机的 19527 端口，这里不需要 Nginx 反代。服务直接监在 0.0.0.0:19527 即可。

3 核心架构决策

3.1 为什么不用 Flask / FastAPI / Django

装不上。没有外网，pip 不可用。apt-get install python3-flask 也不行——Debian 系的 Python 包命名风格和 pypi 不一致，很多现代 Web 框架没有 apt 打好的包。

3.2 为什么不用 Nginx autoindex

apt-get install nginx 理论上可以，但对一台 45TB 数据盘的生产服务器，装 nginx 意味着多一个进程、多一套配置、多一个攻击面。这个文件服务器的需求很简单——列目录、下载文件——Python 标准库完全够用。

3.3 选型对比

Python 标准库方案对这台「无外网 + 生产环境 + PEP 668」的机器是最优解。

3.4 模块选择：ThreadingHTTPServer

Python 3.12 标准库自带了两个 HTTP 服务器：

10-20 人团队，ThreadingHTTPServer 够用。不需要引入 asyncio 或者 socketserver.ForkingMixIn——多线程在这个并发量级下足够。

4 代码实现逻辑

完整代码约 350 行，零外部 import。只用了 Python 3.12 自带的这些模块：

import http.server   # ThreadingHTTPServer, SimpleHTTPRequestHandler
import os            # 文件遍历、路径校验
import re            # URL 路径清理（合并重复 /）
import urllib.parse  # URL 编解码
import sys           # 日志输出
import datetime      # 文件修改时间格式化
from pathlib import Path

4.1 总体结构（三段式）

main()
  ├── 信号处理（SIGINT / SIGTERM 优雅退出）
  ├── 创建 ThreadingHTTPServer((0.0.0.0, 19527), FileHandler)
  └── server.serve_forever()

FileHandler(SimpleHTTPRequestHandler)
  ├── translate_path()     → URL → 文件系统路径（含防穿越）
  ├── do_GET()             → 目录→列表页，文件→下载
  └── list_directory()     → 生成 HTML 目录列表

工具函数
  ├── human_size()         → 字节 → 人类可读（KB/MB/GB）
  ├── format_time()        → Unix 时间戳 → YYYY-MM-DD HH:MM
  ├── build_breadcrumb()   → 生成面包屑 HTML
  └── escape_html()        → HTML 实体转义

4.2 路径安全：防穿越

这是最关键的一行代码。如果用户访问 /../../../etc/passwd，os.path.normpath 会把路径规范化，然后用 os.path.commonpath 检查结果是否仍然在 ROOT_DIR 内：

def translate_path(self, path):
    path = urllib.parse.unquote(path.split("?")[0].split("#")[0])
    rel = path.lstrip("/")
    fs_path = os.path.normpath(os.path.join(ROOT_DIR, rel))

    # 关键：检查最终路径是否在 ROOT_DIR 范围内
    if os.path.commonpath([os.path.realpath(fs_path),
                           os.path.realpath(ROOT_DIR)]) != os.path.realpath(ROOT_DIR):
        return os.path.join(ROOT_DIR, "")  # 越界→返回空路径→404

    return fs_path

这里三处调用 os.path.realpath 是为了处理符号链接绕过——os.path.normpath 只做字符串规范化，不解析软链接。os.path.realpath 把路径解析到真实的 inode，再比较。

4.3 目录列表：HTML 模板渲染

list_directory() 的逻辑：

1. os.scandir(path) 遍历目录（比 os.listdir + os.stat 快，一次系统调用同时拿到文件名和 stat）
2. 目录和文件分两组，各自按名称排序（不区分大小写），目录排前面
3. 每个条目生成 <tr>：图标（📁/📄）、带链接的文件名、人类可读大小、日期
4. 用 HTML_TEMPLATE.format() 填充整页

文件名列没有设固定宽度、没有 text-overflow: ellipsis。CSS 用了 word-break: break-all 和 overflow-wrap: anywhere——文件名多长都能完整显示。这是最早版本用 min-width: 0 + word-break 的组合，测试过 80+ 字符的文件名不会溢出也不换行错乱。

4.4 文件下载：强制下载头

self.send_header(
    "Content-Disposition",
    f'attachment; filename="{urllib.parse.quote(fname)}"'
)

只要请求的是文件（不是目录），就加 Content-Disposition: attachment。不管浏览器能不能内联打开（PDF、图片、txt），都给下载。这是团队明确的需求——这些文件本身就是用来下载的，不是在线预览的。

4.5 深色/浅色切换

用 CSS 自定义属性（--bg、--text 等）+ data-theme 属性切主题：

:root { --bg: #ffffff; --text: #1a1a1a; ... }
[data-theme="dark"] { --bg: #0f172a; --text: #e2e8f0; ... }

JS 就两件事：

1. 页面加载时读 localStorage.getItem('baic-theme')，设置初始主题
2. 点击开关时切 data-theme 属性 + 更新 localStorage

不需要 cookie、不需要后端 session、不需要 CSS 预处理。8 行 JavaScript 解决问题。

5 部署步骤

5.1 上传代码到目标机

通过跳板机 SCP 把本地写好的 baic-server.py 推到目标机：

sshpass -p '<password>' scp \
  -o "ProxyCommand ssh -i ~/.ssh/id_ed25519 herui@10.10.0.4 -W %h:%p" \
  -P 3022 /tmp/baic-server.py sup1whu@112.31.22.151:~/baic-server.py

5.2 验证手动启动

# SSH 到目标机
ssh sup1whu@btk-acloud

# 手动启动，观察输出
python3 ~/baic-server.py

输出：

BiTECH File System running on http://0.0.0.0:19527/
Serving: /data/baic_n60
Press Ctrl+C to stop.

在另一台能访问目标机的内网机器上：

curl -sI http://10.177.100.30:19527/
# HTTP/1.0 200 OK
# Content-Type: text/html; charset=utf-8

Ctrl+C 停掉手动进程，确认端口释放：

ss -tlnp | grep 19527
# 应该无输出

5.3 配置 systemd 用户服务

服务文件路径：~/.config/systemd/user/baic-files.service

[Unit]
Description=BiTECH File System — /data/baic_n60/ file server
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/python3 /home/sup1whu/baic-server.py
Restart=always
RestartSec=5
WorkingDirectory=/home/sup1whu

[Install]
WantedBy=default.target

每个参数的含义：

5.4 启用 linger + 启动服务

用户级 systemd 服务默认只在用户登录时运行。这个机器没有图形界面、没有常驻登录会话，需要开启 linger 让服务在系统启动时就起：

# 允许 sup1whu 用户在系统启动时自动起服务（不需要登录会话）
sudo loginctl enable-linger sup1whu

# 重载 systemd 用户实例、启用服务
systemctl --user daemon-reload
systemctl --user enable baic-files.service
systemctl --user start baic-files.service

三步的区别：

验证：

systemctl --user status baic-files --no-pager

输出示例：

● baic-files.service - BiTECH File System — /data/baic_n60/ file server
     Loaded: loaded (.../baic-files.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-07-15 17:04:46 CST; 2h ago
   Main PID: 2145802 (python3)
      Tasks: 1 (limit: 38415)
     Memory: 10.2M (peak: 11.1M)

内存 10MB——对于一个 HTTP 服务器来说很少。ThreadingHTTPServer 只在有请求时才起线程，平时就一个主线程。

5.5 功能验证

用 curl 跑了 7 项测试：

6 运维管理常用命令

6.1 日常操作

6.2 更新代码流程

# 1. 本地修改 baic-server.py，测试通过
python3 /tmp/baic-server.py &
curl -sI http://127.0.0.1:19527/
kill %1

# 2. 通过跳板机推到目标机
sshpass -p '<password>' scp \
  -o "ProxyCommand ssh -i ~/.ssh/id_ed25519 herui@10.10.0.4 -W %h:%p" \
  -P 3022 /tmp/baic-server.py sup1whu@112.31.22.151:~/baic-server.py

# 3. 重启服务（systemd 用新代码）
sshpass -p '<password>' ssh \
  -o "ProxyCommand ssh -i ~/.ssh/id_ed25519 herui@10.10.0.4 -W %h:%p" \
  -p 3022 sup1whu@112.31.22.151 \
  "systemctl --user restart baic-files && systemctl --user status baic-files --no-pager"

不要直接在目标机上用 vim 改代码然后 systemctl --user restart。目录 /data/baic_n60/ 是生产数据，vim 出错了没有 git 回滚。

6.3 磁盘监控

7 踩坑记录

7.1 PEP 668：externally-managed-environment

最开始想在目标机上 pip install flask，报错：

error: externally-managed-environment
× This environment is externally managed

Ubuntu 24.04 默认的 Python 3.12 开启了 PEP 668 保护——禁止 pip 往系统 site-packages 装东西。这是好事，保护系统 Python 不被破坏，但意味着不能走常规的 pip 安装路线。

绕不过去：

• pip install --break-system-packages：语法上能绕过 PEP 668，但没网，pypi.org 连不上
• python3 -m venv + pip：同样卡在外网上
• apt-get install python3-flask：Debian/Ubuntu 没有 Flask 的 apt 包

回到标准库。http.server.ThreadingHTTPServer 在这个并发量级下够了。

7.2 systemd 用户服务不启动

systemctl --user enable baic-files 成功后重启机器服务没起来。检查：

loginctl show-user sup1whu | grep Linger
# Linger=no

用户服务在 session 级别启动。没有 linger 的情况下，WantedBy=default.target 不会在系统启动时触发——因为 default.target 对于用户实例，只有在用户首次登录时才启动。

修复：sudo loginctl enable-linger sup1whu，下次重启服务就自动起来了。这个行为在 systemd 官方文档 logind.conf(5) 里有说明，但不踩这个坑不会注意到。

7.3 ExecStart 写 python3 而不是 /usr/bin/python3

systemd 用户实例的 $PATH 非常精简（大概只有 /usr/local/bin:/usr/bin:/bin），但行为与登录 shell 不同。直接用 python3 虽然大概率能跑（因为 /usr/bin 在 PATH 里），但写绝对路径 /usr/bin/python3 消除了所有不确定性。systemd 官方文档也在 systemd.service(5) 里建议 ExecStart 用绝对路径。

7.4 从临时进程切换到 systemd 时的端口冲突

手动 python3 ~/baic-server.py & 启动的进程在后台跑着，后来 systemctl --user start baic-files 也起了。两个进程抢 19527 端口，后者报 Address already in use。

systemd 的 Restart=always 会不断重试，日志里刷了一串失败。手动 kill 掉旧进程后 systemd 自动恢复。

先停手动进程、再起 systemd。如果已经乱了，pkill -f baic-server.py 清掉所有残留，systemd 会在下一个 RestartSec 后自动拉起来。

8 最终状态一览

整个部署从零到 production-ready 花了一个小时——其中 30 分钟在调研「无外网 + PEP 668」环境下的可行方案，20 分钟写代码，10 分钟部署 + 验证。

手上有两张招行卡，一张借记卡一张信用卡。最近整理快捷支付授权列表的时候发现，不知不觉绑了十几个平台——有些完全想不起来什么时候授权的。

仔细一想，每个平台都能从我的卡里扣钱，但我对它们的安全机制几乎一无所知。唯一的判断标准是「大厂，应该没事吧」。

花了一周时间逐个查这些平台背后的持牌机构、央行处罚公示、安全白皮书和公开披露的安全事件。查下来的结果让我挺意外的——差距远比我预想的大。Apple Pay 和云闪付用的是同一套硬件级 Token 方案，而拼多多 App 刚被 Google 因为利用 Android 0-day 漏洞收集用户数据从 Play 商店全线撤下。这中间差了不止一个量级。

这篇文章把查到的东西整理出来，方便自己以后参考。数据来源都在文中标了，主要是央行行政处罚公示、移动支付网公开统计和澎湃新闻/央广网的报道。有错的欢迎指正。

一、决定安全的三个技术分水岭

分析完 17 个平台后发现，真正拉开安全差距的不是公司名气，是三个硬指标：

第一个，有没有 Token 化。 Token 化意味着平台和商户都不接触你的真实银行卡号，只用一个受限的虚拟令牌替代。这个令牌可以限设备、限商户、限单次。没有 Token 化的平台，你的卡号直接存在它们的系统里——你对它的信任本质上就是赌它的数据库不会被拖走。

第二个，风控引擎的成熟度。 关键指标是交易量 × 拦截率。支付宝的 CTU 每秒处理 40 万笔交易，这是十几年积累下来的模型能力。腾讯天御借助微信社交关系图谱做异常检测，把资金损失率压到了业内罕见的水平。而一些中小支付机构的风控，技术上约等于黑名单匹配加简单规则。

第三个，有没有安全事件前科。 这是最直白的信号。一次严重安全事件，暴露的不是一个 bug，而是一家公司在安全工程和合规文化上的系统性缺陷。携程 2014 年的日志明文记录 CVV 码，拼多多 2023 年把安全能力用在攻击用户隐私上——这类记录不会因为「已经整改了」就应该被忽略。

下面是 17 个平台在这三个维度上的全量对照。

二、技术框架总览

2.1 核心安全机制对比

2.2 加密标准与合规认证

三、监管处罚记录

2025 年全年，人民银行及各地分支机构合计对支付机构开出 80 张罚单，罚没金额合计约 2.88 亿元，较上年度（剔除对银联股份的处罚）增长超过 50%。其中支付结算领域 69 张（2.62 亿元）、综合罚单 7 张（2287 万元）、反洗钱领域 4 张（338 万元）。

这仅是一年的数据。下面是与本文相关的平台和其持牌机构被处罚的核心记录。

3.1 监管处罚明细

关于网银在线（京东支付）：六年累计已被央行处罚五次，累计罚没超过 4200 万元。2025 年两次罚单间隔仅 7 个月，违规类型覆盖支付结算、反洗钱、备付金管理等几乎所有监管领域的常见违规项。黑猫投诉平台上有超过 3000 条「不知情扣款」相关投诉。

3.2 行业处罚趋势

来源：移动支付网《2025年中国人民银行支付机构处罚分析》

四、安全事件记录

监管罚单反映的是合规能力，安全事件反映的是工程能力。两者加在一起才能判断一个平台到底值不值得信任。

五、隐私策略对比

支付安全和隐私保护是两件事。一个平台可以技术上很安全（不丢钱），同时隐私上很危险（数据被用于你不愿意的用途）。

六、逐平台深度分析

第一梯队：几乎无懈可击

Apple Pay

Apple Pay 的安全模型和所有其他平台都不同。它不存储你的银行卡号，不追踪你的交易，风控也完全交给发卡行——Apple 自己只负责硬件和身份验证。

核心机制：当你把招行卡添加到 iPhone 的 Wallet App 时，系统通过银联向招行发起验证请求。招行验证你的身份后，生成一个唯一的设备账户号（DAN：Device Account Number），直接写入 iPhone 的 Secure Element 芯片里。

Secure Element 是一块独立于主 CPU 的硬件安全芯片。iOS 系统和任何 App 都读不到里面存了什么。物理拆解会触发芯片自毁。每一笔支付在 Secure Element 内部生成一次性的动态安全码，和 DAN 配对使用。即使有人截获了这笔交易的数据，也无法用于第二次支付。

Apple 能做到这么干净，本质原因是它的商业模式不靠支付数据变现。硬件利润、App Store 抽成和服务订阅已经极端丰厚了，没有必要为了多赚一点去碰用户的交易隐私。在这个行业里，商业模式天然决定了隐私保护的上限。

云闪付

云闪付走的是国际标准的 EMVCo Token 化体系——和 Visa、Mastercard 的 Token 服务同一套规范。银联的角色是中国银行卡清算组织，直连央行。这意味着它的数据只用于清算和反欺诈，没有商业变现压力。你不会担心银联拿你的消费记录去做推荐算法。

风控分三段：绑卡时用 Token 替代真实卡号（前防），交易中实时评估并及时拦截异常（中控），出了事只要用户无过错就全额赔付、没有赔付上限（后偿）。这个「无上限」承诺在中国第三方支付行业里是独一份的。

如果说 Apple Pay 是借助硬件做到了安全性最优，那云闪付就是在监管位置和数据用途上的最优解——没有商业变现动机，就没有数据滥用的风险。

银联在线支付

银联在线支付是传统的网关支付，不走第三方平台的账户体系。交易时需要同时输入完整卡号、取款密码、手机验证码和 CVV（四重验证），通过银联网关直连招行扣款。整个过程中间没有第三方机构持有你的账户信息。

代价就是流程繁琐——每次都要手打一堆数字。日常小额用它不现实，但大额付款或对安全性有极端要求的时候，它是理论上最安全的选择。四个验证因子同时被泄露或截获的概率极低。

第二梯队：成熟但各有隐忧

支付宝

支付宝的安全体系在全球支付机构里属于第一梯队。CTU（Creditable Transaction Unit）风控引擎对外公布的指标是每秒处理 40 万笔交易，背后的模型是一个深度学习神经网络加若干规则引擎的组合。2022 年支付宝在公开报告中披露过，全年拦截风险交易超过 200 亿次。

几个具体技术点：

• 3D 活体检测通过了国家金融科技认证中心认证，误识率低于十亿分之一（10⁻⁹）。照片、视频重放、3D 打印面具都能识别。
• 设备指纹采集了超过 100 个维度的硬件和软件特征——包括传感器特性、屏幕参数、字体列表。模拟器和多开环境会被直接拒绝，也可以检测出设备是否被 root 或越狱。
• 行为生物特征在后台静默运行——击键节奏、触屏压力曲线、滑动轨迹。你自己感觉不到，但换一个人用你的手机支付，模型能立刻捕捉到行为模式的变化。

从隐私角度看，支付宝数据用途的透明度不算高。蚂蚁集团虽然已完成整改，但其信贷（花呗借呗）、保险（相互宝/好医保）、理财（余额宝/蚂蚁财富）与支付数据本质上在一个生态内流转。如果我是招行用户，在支付宝上做日常支付可以接受，但不会让支付宝成为我唯一的支付入口。

史上最大罚单：2023 年 7 月，央行对支付宝开出 银罚决字【2023】26-33 号 罚单，罚没合计 30.6 亿元（没收违法所得 8.31 亿 + 罚款 22.31 亿），涉及 7 项违法行为。同时蚂蚁集团也被穿透式处罚。这个金额是全球支付行业有史以来最高的单笔罚款。

来源：澎湃新闻 / 央广网

财付通（微信支付）

腾讯做支付安全有一个别人复刻不了的优势：社交图谱。

财付通的风控系统叫「天御」，它在决策一笔交易是否可疑的时候，能参考的不只是交易本身的金额、时间、地理位置，还包括支付双方的社交关系、设备登录历史、位置变动轨迹。比如一个你从未联系过的账户突然向你发起大额转账，或者你的微信账号同时在两个相距 500 公里的设备上登录——天御能在毫秒级捕捉这种异常。

效果反映在一个数字上：财付通的资金损失率在 2022 年压到了十五万分之一。这个数字在全球支付机构里都是顶尖的。

2023 年 7 月与支付宝同期，财付通也被央行罚没 29.9 亿元（没收 5.66 亿 + 罚款 24.27 亿）。同样的压力测试下活下来的平台，内控合规至少是被强制矫正过的。

真正的风险不在支付安全本身，而在隐私边界。微信支付和微信聊天是同一家公司运营的。虽然腾讯官方承诺「支付数据不用于广告推荐」，但没有第三方独立审计可以验证。作为用户，你只能选择信任这个承诺——或者不用。

京东支付

先说好的：京东支付的风控利用了电商和物流数据的天然优势，事先的设备指纹采集、事中的实时评分、事后的离线审计——全链路反欺诈框架是完整的。

再说具体的：它的持牌机构网银在线，六年被央行罚了五次。

来源：移动支付网 / 腾讯新闻

六年累计罚没超 4200 万元的持牌支付机构，技术和合规之间是割裂的。另外京东 2016 年发生过 12GB 用户数据泄露，黑猫投诉上还有 3000 多条「不知情扣款」的记录。我个人只在京东上买自营商品时用京东支付，其他地方一律走微信或支付宝。

第三梯队：支付不算差，隐私让人担心

抖音支付

抖音支付本身的支付通道安全性不用太担心——2048 位 RSA 加密传输，央行持牌（合众易宝），字节跳动的 AI 能力能提供较强的异常检测。在抖音里买东西，用抖音支付还是用支付宝付钱，被盗刷的风险差异不大。

问题全在隐私上。

字节跳动的商业模式建立在深度学习用户行为之上。你用抖音刷视频、看直播、在商城下单、然后用抖音支付付款——所有这些行为数据完整地留在了同一套系统里。一个平台同时掌握你的内容消费偏好、社交互动记录和完整的支付交易明细。它说「支付数据与推荐系统隔离」，但没有第三方审计能验证。

我自己的做法是：抖音买东西只走支付宝。虽然两种方式的支付安全差不多，但至少支付宝不会把支付数据和我的短视频观看记录放在一起。

美团支付

和抖音的问题是同一类：不是支付不安全，是生态内数据太集中。外卖地址、到店消费、酒店入住、电影票预订，加上支付流水——这几乎是一个人的完整线下活动画像。

技术上，美团的风控利用了场景数据的天然优势。一个长期在北京叫外卖的账号突然在深圳产生一笔凌晨酒店支付——这种异常信号对美团来说太容易捕捉了。但美团「杀熟」争议（不同手机、不同用户看到不同价格，反复被用户实测验证）也从侧面说明它的数据分析和用户画像能力极强。

小米钱包

分两条路径看：

• NFC 闪付（Mi Pay）：走银联 Token 化通道，用手机 Secure Element 芯片存储，和 Apple Pay 原理一致。这部分的安全性取决于硬件，小米旗舰机的 eSE 方案是可靠的。
• 线上绑卡到小米钱包 App：走捷付睿通自有通道。捷付睿通是小米全资子公司，2026 年 5 月因「违反反洗钱管理规定」被央行内蒙古分行处罚，文件编号 蒙银罚决字〔2026〕3 号，罚款 167.1 万元。这已经是捷付睿通成立以来第四次被罚。

来源：移动支付网 / 中国经济网

另外，MIUI 作为操作系统，在系统层面对用户设备拥有最高权限。硬件设备行为、IoT 设备数据、商城消费加上支付数据，全部在小米的生态内。如果你用的小米手机已经是主力机了，可以再给小米钱包增加权限——但需要知道这意味着什么。

翼支付与和包支付

两家运营商旗下的支付工具放一起说，因为它们面临同一个核心问题：数据维度太多了。

中国电信有 3 亿多实名用户，中国移动超过 14 亿（含物联网卡）。运营商手里本来就有身份证信息、实时位置轨迹、通话记录、上网日志。现在再加上支付交易流水和消费记录——这个数据集可以画出一个人生活的几乎全部轮廓。

安全性上，国企的合规约束比民营平台严格，目前没有发生过重大泄露或盗刷事件。但翼支付账户直接绑定手机号，如果号码被人恶意挂失补卡，支付账户跟着就危险了。两家都有运营商特有的免费挂失保障，但前提是你及时发现。

日常生活中用不上这两家就不用绑。如果你已经是电信或移动的长期用户，只绑一张小额借记卡并设好日限额。

第四梯队：有安全硬伤

拼多多支付

拼多多支付背后的持牌机构是上海付费通。但核心问题不在付费通——在拼多多这个母公司对待用户数据的根本态度。

2023 年 3 月，Google 的安全团队（Project Zero 级别的 Android 安全研究能力）发现拼多多 App 利用了 Android 系统未公开的漏洞——不是普通 bug，是 0-day 级别的安全漏洞——绕过用户授权读写其他 App 的私有数据、修改系统设置。Google 随即将拼多多从 Play 商店全线下架，持续了几个月。

关于这个事件有几个关键点：

• 利用 0-day 漏洞需要极高的安全研究能力。这意味着拼多多雇佣了具备攻击性安全研究能力的人，把能力用在了用户身上
• 工信部、网信办多次通报拼多多「违规收集个人信息」「超范围收集个人信息」「强制用户使用定向推送功能」
• 这些不是一次性疏忽，是持续多年的隐私合规问题

你愿意让一家把高水平安全能力用在你身上的公司保管你的银行卡信息吗？在拼多多买东西用微信支付或支付宝结算就够了——完全没必要把卡直接绑给拼多多支付。

携程支付

2014 年 3 月，乌云漏洞平台上了一份报告，后来被包括《财经》在内的媒体广泛转载：携程的支付系统日志直接打印并存储了用户的银行卡号、CVV 安全码、有效期——以明文形式。

PCI-DSS 安全标准有明确规定：CVV 在任何情况下都不允许被存储。加密也不行。不允许。这是支付安全行业一个绝对红线。

能犯这个错误，说明在事发时携程支付的安全评审流程、代码审查制度和员工 PCI-DSS 培训全部没有起到该起的作用。单个工程师不可能独立导致这种后果——这是一个组织层面的合规和文化问题。

需要承认的是，十年过去了，携程的安全体系和 2014 年已经完全不同。但这件事情的意义在于：它让我们看到了一个支付系统在不被监管真正穿透审查时，底线可以低到什么程度。

任何时候在携程买机票酒店，用微信或支付宝支付，不要绑定携程支付。

通联支付与富友支付

这两家的主营业务是面向商户的 B 端收单，个人用户很少直接接触。但如果你在某个线下商户被引导扫码付款时跳到了它们的页面，需要知道背景。

通联支付：2016 年被央行通报「严重违规」，罚款 1110 万元。历史累计处罚超千万元，涉及银行卡收单违规、反洗钱违规。2023 年还牵涉到一起 9000 万元非法吸收公众存款关联案件。

富友支付：多次因反洗钱违规和数据报送问题被央行处罚，消费者投诉累计上千条。一直在冲击港股上市但反复受挫，被市场质疑的点之一是在 IPO 前进行了超过净利润 3.65 亿元的「清仓式分红」。

这两家如果作为消费者在终端碰到，不要绑定任何银行卡。

苏宁支付与唯品支付

苏宁支付（易付宝）：苏宁集团近几年经营持续困难，由国资托管转型中。技术团队和安全投入大概率在缩减。没有重大安全事件记录，但也毫无技术亮点。

唯品支付：2016 年用户数据泄露事件包含支付信息。作为垂直品牌特卖电商平台，安全团队规模与大厂不在同一量级。

七、快速决策参考

如果你只想要结论，下面这张表是你需要的全部信息：

7.1 绑卡建议总表

7.2 按使用场景的选择

八、如果你只看这一节

绑卡安全这件事上，有几个原则比任何技术分析都重要：

1. 开一张 II 类账户专门做快捷支付。 招行 II 类账户每日进出限额 1 万元，把这张卡绑到各个支付平台上去。主力借记卡保持在所有外部渠道之外。最坏的情况下某个平台出问题，损失也卡在可控范围。

2. 招行 App →「快捷支付管理」→ 每月看一遍。 把不认识或者已经不用的授权直接关掉。很多平台授权一次就永久有效，时间长了你自己都忘了绑过哪些。

3. 大额付款统一用信用卡。 信用卡有 48 小时盗刷保障，争议交易可以拒付。借记卡是存款被直接划走，追讨流程慢得多——而且追回来之前这笔钱你用不了。

4. 绑定新平台的同时立刻设限额。 招行 App 里可以按商户设单日单笔限额。就算平台出问题，损失的区间也是锁死的。

5. 安全这件事，分散风险不如减少风险面。 不是铺开 17 个支付方式就能降低风险。少绑一个不靠谱的平台，比给 17 个平台都设好限额更安全。尤其是有历史污点的平台——第一次出问题是意外，多次出问题就是模式了。

数据来源：中国人民银行总行及各地分支机构行政处罚信息公示、移动支付网公开统计、澎湃新闻、央广网、乌云漏洞平台（WooYun，已停止运营）、Google Android 安全团队公开披露。本文写于 2026 年 7 月，各平台安全状况动态变化中，建议每半年复查一次。如有事实错误或需补充的内容，欢迎指出。

网络架构

Hermes 的部署拓扑：

• 管理节点通过 WireGuard 接入公司内网，网段 10.10.0.0/24
• 10.10.0.4 上运行 Nginx 反向代理，监听 0.0.0.0:8000，后端接 DeepSeek 网关
• 所有 API 请求统一走 http://10.10.0.4:8000/v1

这条链路踩过坑。Nginx 不传 Authorization 头、超时不够、Host 路由不对都遇到过，后面踩坑记录里展开。

可用模型

日常启动与退出

启动

hermes

在钉钉群里 @机器人 或在私聊里直接发消息即可交互。命令行环境下直接输入文本对话。

对话中常用操作

模型选择与切换

规则引擎速查

Hermes 支持通过 config.yaml 中的 rules 配置按关键词自动匹配模型。例如：

rules:
  - keywords: ["架构", "架构设计", "系统设计"]
    model: deepseek-v4-pro
    provider: company-deepseek-v4
  - keywords: ["翻译", "translate"]
    model: deepseek-v4-flash
    provider: company-deepseek-v4-flash

每条规则包括：

• keywords — 匹配用户输入的关键词列表
• model — 指定使用的模型名
• provider — 对应的后端 provider（可选）
• priority — 规则优先级（数值越大越优先，默认 0）

匹配后自动切换，不需要手动干预。

临时切换模型

在对话里随时切，不影响上下文：

/model deepseek-v4-pro

也可以传 provider+model：

/model company-deepseek-v4/deepseek-v4-pro

多话题会话管理

这是近期新增的功能：一个 Hermes 实例里同时跑多个独立会话，互不干扰。

使用场景

假设你同时处理三个话题：

每个会话有自己的对话历史、上下文和模型配置。启动新话题：

/new 技术架构

然后在对话中设置模型：

/model deepseek-v4-pro
/title 技术架构

这样下次通过 hermes --continue 技术架构 就能直接回到这个对话。

查看所有会话

hermes sessions list

输出会列出每个会话的 ID、名称、最后活跃时间。也可以用交互式界面浏览：

hermes sessions browse

会话操作速查

进阶：Profile 完全隔离

如果希望话题之间完全隔离——独立的记忆、独立的配置、甚至独立的 API Key——可以创建多个 Profile：

# 创建新 profile
hermes profile create 工作-架构设计

# 在该 profile 下配置不同的模型
hermes config set model deepseek-v4-pro --profile 工作-架构设计

# 使用指定 profile 启动
hermes --profile 工作-架构设计

每个 Profile 有自己独立的 skills、plugins、cron 和 memories。

常用命令速查

基础命令

模型切换

会话管理

系统维护

踩坑记录

以下是实际部署过程中踩过的坑。

❌ Nginx 反代导致 401 认证错误

现象：客户端配置了正确的 API Key，但请求始终返回 401。

原因：Nginx 默认不会透传 Authorization 请求头。反向代理到后端时，这个头被丢了。

修复：在 Nginx 的 location 块里显式加上：

proxy_set_header Authorization $http_authorization;

这个坑踩了两次——正常对话没问题，但上下文压缩（生成大请求）时偶发 401，因为压缩请求走了不同的连接路径，偶尔触发同一根因。

❌ Realm 转发导致 404

现象：使用 Realm 做流量转发，所有请求返回 404。

原因：Realm 不支持修改 Host 头，公司网关依赖 Host 做路由决策。

解决：放弃 Realm，改为 Nginx proxy_pass 直接反代。

❌ 请求超时

现象：长文本生成或复杂推理中途被断开，客户端收到超时错误。

原因：Nginx 的 proxy_read_timeout 默认只有 60 秒，AI 后端生成长回复时经常超过这个时间。

修复：

proxy_read_timeout 600s;
proxy_connect_timeout 60s;
proxy_send_timeout 60s;

确保同时使用 HTTP/1.1 长连接：

proxy_http_version 1.1;
proxy_set_header Connection "";

故障排查

快速诊断

遇到问题时按顺序执行：

# 1. 检查 WireGuard 连通性
ping 10.10.0.4

# 2. 检查 Nginx 是否存活
curl -s -o /dev/null -w "%{http_code}" http://10.10.0.4:8000/v1/models

# 3. 检查 Hermes 自身状态
hermes doctor

# 4. 查看最近日志
tail -100 ~/.hermes/logs/hermes.log

常见问题

附录 A：Nginx 优化配置参考

server {
    listen 8000;
    server_name _;

    location /v1 {
        proxy_pass http://<upstream>;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header Authorization $http_authorization;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 600s;
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
    }
}

三个要点：超时设到 600 秒、显式转发 Authorization 头、用 HTTP/1.1 长连接避免频繁握手。

文档基于 Hermes Agent 公开发布版本及公司内部部署实践整理，配置参数和功能以实际部署版本为准。文档编号：DOC-2026-0708-HERMES-V2。

我有一个域名 raysre.com，放在那儿很久没什么用。最近打算把它变成个人博客——要求很简单：纯静态、不维护服务器、更新成本接近零。

选了 Hugo（Go 写的静态站点生成器，hugo build 整个站点不到 200ms）+ PaperMod 主题（极简，不需要 Webpack/PostCSS 那一套）。托管在腾讯云 COS（对象存储），套一层 EdgeOne（腾讯云的边缘加速产品，对标 Cloudflare），通过 GitHub Actions 推送代码自动上线。

这条路踩了几个坑。COS 的「公有读私有写」和 EdgeOne 的「私有访问授权」组合在一起会产生一个让人摸不着头脑的 AccessDenied。调试过程花了不少时间翻文档，顺带把 EdgeOne 和 COS 里那些没用到但经常被问到的功能也一并理了。

这篇文章是从零到上线的完整记录，加上排查过程、配置解读、概念速查。没用到腾讯云功能的内容放进进阶参考，最后附 FAQ。

整体架构

各组件分工：

数据流是单向的：

开发者 git push → GitHub Actions → hugo build → public/ → Python SDK 上传 COS → CDN 刷新
用户访问 raysre.com → EdgeOne 边缘节点（缓存命中）→ 返回缓存 → 用户
                           ｜缓存未命中 → 回源 COS → 返回

这个架构对个人博客来说有几个好处：不需要买云服务器，不需要维护 Nginx，COS 存储一个月几毛钱，EdgeOne 免费套餐 10GB/月流量够用。

基础概念速查

配置过程中反复出现的几个概念，放在这里免得后面看不懂。

关键理解：COS 有两套域名体系。

EdgeOne 如果用「对象存储源站」模式回源到默认域名，走的不是静态网站逻辑。你用浏览器访问 https://raysre.com/index.html，EdgeOne 回源时相当于向 COS 的 API 端点发起 GET 请求，这时候如果桶是私有读，会直接返回 AccessDenied——这就是后面排查过程中掉进去的坑。

Step 1：Hugo 环境搭建

Hugo 用的是 v0.164.0 extended 版 + PaperMod 主题。注意 PaperMod 是 submodule，克隆仓库时带 --recurse-submodules：

# 新建站点
hugo new site raysre.com --format yaml
cd raysre.com

# PaperMod 主题
git submodule add https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod

hugo.toml 核心配置（60 行，去掉了默认配置的冗余项）：

baseURL = 'https://raysre.com/'   # 生产环境域名，决定所有绝对链接
locale = 'zh-cn'
title = 'DevOps工作笔记'
theme = 'PaperMod'
[params]
  description = '工作与生活随记'
  author = '阿端'
  ShowToc = true                  # 显示文章目录
  ShowBreadCrumbs = true          # 面包屑导航
  ShowReadingTime = true
  ShowWordCount = true
[markup.tableOfContents]
  startLevel = 2                  # 目录只显示 h2/h3
  endLevel = 3

构建命令：

hugo --minify           # 构建并压缩，输出到 public/
hugo server -D          # 本地预览，--watch 默认开启

备案展示——PaperMod 默认的 footer.html 没有备案号。在 layouts/partials/footer.html 里加了：

<div style="text-align:center;font-size:12px;color:#888;margin-top:10px">
  <a href="https://beian.miit.gov.cn/" target="_blank" rel="noopener">
    沪ICP备2026021650号-1
  </a>
  <span style="margin:0 8px"></span>
  <a href="http://www.beian.gov.cn/portal/registerSystemInfo?recordcode=31011502406637"
     target="_blank" rel="noopener">
    <img src="/images/beian.png" style="display:inline;height:14px;vertical-align:middle" alt="">
    沪公网安备 31011502406637 号
  </a>
</div>

公安备案图标 beian.png 放 static/images/ 下，构建时会原样复制到 public/images/。

Step 2：COS 存储桶配置

腾讯云 COS 控制台操作清单：

关于访问权限的最终方案：

桶设为私有读写，在 EdgeOne 里开启私有访问授权。EdgeOne 回源 COS 时会带上内部鉴权签名，COS 认这个签名放行。用户在浏览器里直接打 COS 默认域名会返回 403。

这样做的好处：COS 源站不暴露公网入口，只有 EdgeOne 能回源取文件。

Step 3：GitHub Actions 自动部署

deploy.yml 总长 145 行，分 5 个步骤：

Setup Hugo 步骤：从 GitHub Releases 直接下载，不用 peaceiris/actions-hugo 这种第三方 Action——少依赖就是少隐患。指定版本 0.164.0 防止某天自动升版导致构建行为变化。

Deploy 步骤逐段拆解：

# 第一段：MIME 类型映射表
MIME = {
    '.html': 'text/html; charset=utf-8',
    '.css':  'text/css; charset=utf-8',
    '.js':   'application/javascript; charset=utf-8',
    '.svg':  'image/svg+xml',
    # ... 16 种常见格式
}

不设 Content-Type 的话，COS 默认给所有文件 application/octet-stream。浏览器拿到不认识就当成下载，CSS/JS 不生效，页面直接崩。所以每个文件上传时必须带正确的 MIME。

# 第二段：遍历上传
local_dir = 'public'
uploaded = 0
for root, dirs, files in os.walk(local_dir):
    for f in files:
        local_path = os.path.join(root, f)
        cos_key = local_path[len(local_dir):].lstrip('/')
        ext = os.path.splitext(f)[1].lower()
        content_type = MIME.get(ext, 'application/octet-stream')
        with open(local_path, 'rb') as fp:
            client.put_object(
                Bucket='raysre-1377355589',
                Key=cos_key,
                Body=fp,
                ContentType=content_type
            )
        uploaded += 1

os.walk() 递归遍历 public/ 下所有文件，cos_key 去掉了 public/ 前缀。比如 public/posts/hello/index.html 上传后 COS Key 就是 posts/hello/index.html，直接和 URL 路径对应。

为什么用 Python SDK 而不是 coscmd：

Purge CDN 步骤：调腾讯云 CDN API PurgeUrlsCache，签 V3 签名算法（TC3-HMAC-SHA256），刷新首页和 www 两个 URL。Hugo 新构建的文件名含 hash（如 main.abc123.css），自然绕过旧缓存——所以不需要全站刷新，只刷首页让用户拿到新文件引用就够了。

Secrets 配置：TENCENT_SECRET_ID 和 TENCENT_SECRET_KEY 必须放 GitHub Repository secrets（不是 Environment secrets）——走 Environment 的话 deploy.yml 里 ${{ secrets.XXX }} 拿不到值。这个区分是排查早期构建失败时发现的。

Step 4：EdgeOne 配置 & AccessDenied 排查

第一版配置（翻车）

git push 后 Actions Run #9 成功上传 30+ 个文件但浏览器访问 https://raysre.com/ 返回 AccessDenied XML：

<Error>
  <Code>AccessDenied</Code>
  <Message>Access Denied.</Message>
  <Resource>/</Resource>
  <RequestId>...</RequestId>
</Error>

而直接访问 COS 静态网站端点 http://raysre-1377355589.cos-website.ap-shanghai.myqcloud.com/ 能正常显示。

定位过程

做了几个测试：

根因：EdgeOne「私有访问授权」开启时，会构造一个鉴权签名放在回源请求中。但这个签名是针对 COS API 端点的——不是针对静态网站端点的。而用「对象存储源站」模式回源的地址恰恰好是 API 端点地址（默认域名）。COS 收到带签名的请求后发现签名和请求不匹配：API 端点期望的签名格式和静态网站的授权逻辑不一样。

换句话说：公有读桶 + 私有访问授权 = 冲突。公有读桶不需要鉴权就能访问，开了私有访问授权反而让 EdgeOne 构造了一个多此一举的签名，COS 校验失败直接拒。

修复版本（正确配置）

修复逻辑：先让 EdgeOne 去 COS 完成授权绑定，等 COS 桶策略里出现一条允许 EdgeOne 服务访问的策略后，再把桶改为私有读写。这样 EdgeOne 回源带签名，COS 认这个签名放行。外面直接打 COS 默认域名因为没有签名，直接 403。

附加规则

URL 重写（解决 / 不自动返回 index.html）：

这一步是关键。EdgeOne 回源到 COS API 端点时 GET / 不等于 GET /index.html，不像 Nginx 那样有 try_files。不加这个规则首页永远 403。

www 301 重定向：

${uri} 是 EdgeOne 内置变量，保留原始路径。比如 www.raysre.com/posts/xxx → raysre.com/posts/xxx，不会全部丟到首页。

Step 5：DNS 切换

DNSPod 控制台里把 raysre.com 和 www.raysre.com 的 A 记录删掉（如果之前指向了服务器 IP），改成 CNAME：

TTL 设 600 秒（10 分钟），初次调试时改配置能更快生效。稳定运行后可以调回 3600。

成本估算

以我这个站的实际用量（文章 3 篇、访问量可以忽略）：

对个人博客来说几乎免费。唯一需要留意的：CDN 免费套餐每月 10GB 国内流量，如果哪天文章被大量访问超额，按量计费部分 ¥0.21/GB——设置好「用量封顶」防止意外。

进阶参考：没用到的腾讯云功能

下面这些是 EdgeOne 和 COS 提供的功能，个人博客场景用不到，但如果你要从静态博客拓展到更复杂的场景，可以参考。

EdgeOne 四层代理（L4 Proxy）

用 TCP/UDP 协议加速，适用场景是游戏加速、IoT 设备通信、实时音视频——不走 HTTP。静态博客只用七层（HTTP/HTTPS）。

EdgeOne 边缘函数（Edge Functions）

在 EdgeOne 边缘节点上跑 JavaScript 代码，类似 Cloudflare Workers。可以做的事：自定义鉴权、A/B 分流、响应头注入、内部重定向。比规则引擎灵活，但需要写代码。如果你要实现「特定 IP 段跳转到维护页」这种逻辑，用边缘函数比规则引擎方便。

回源限频

限制 EdgeOne 向源站发起的请求频率。作用是高并发时保护源站不被击穿。文档里典型的参数是「同一 URL 每秒最多回源 1 次」。个人博客流量小，可以不开。

EdgeOne 用量封顶

设置流量 / 带宽 / QPS 上限，达到后自动限速或返回提示页。建议设一下——免费套餐有额度限制，防止某个月被刷流量产生天价账单。

COS 回源设置

当请求的对象在 COS 桶里找不到时，自动去一个预设地址拉取内容。用于数据热迁移场景（如从旧服务器逐步搬到 COS）。不用于静态博客——所有文件由 GitHub Actions 上传，不会出现 404。

COS 生命周期管理

自动把对象从标准存储切换到低频 / 归档 / 深度归档，或到期后自动删除。如果你的桶存了大量日志需要定期清理，这是一个有用的功能。

COS 智能分层存储

自动在「高频」和「低频」两个访问层之间迁移对象，不需要手动配生命周期。访问模式不可预测时比生命周期省心。

数据万象 CI（图片/音视频处理）

和 COS 绑定的数据处理服务，提供实时图片裁剪、水印、格式转换（比如 ?imageMogr2/thumbnail/200x），以及视频转码、截帧等能力。如果你以后需要在文章里自动生成缩略图、加水印，数据万象是实现方案之一。

COS 标签管理

给对象打标签（如 env=prod, category=blog），方便分类、成本核算和批量操作。

FAQ

Q：为什么 hugo.toml 不用 yaml 格式？

hugo new site --format yaml 生成的就是 TOML（这个参数有点误导，实际上 Hugo 默认生成 TOML）。TOML 比 YAML 更不容易出现缩进错误，而且 Hugo 文档里的示例代码基本是 TOML，复制粘贴改起来方便。

Q：deploy.yml 在 GitHub Actions 里报 ModuleNotFoundError: No module named 'qcloud_cos' 怎么处理？

- run: pip install cos-python-sdk-v5

加在 Deploy 步骤最前面。注意每次 step 的 shell 环境可能不同，pip install 放在同一个 run: 块里，不要跨 step。

Q：如何验证 COS 静态网站端点正常工作？

curl -sI http://raysre-1377355589.cos-website.ap-shanghai.myqcloud.com/index.html

预期返回 200 OK + Content-Type: text/html。如果不是 200，去 COS 控制台检查静态网站托管是否开启、默认首页是否设了 index.html。

Q：HTTPS 证书怎么搞？

EdgeOne 免费提供 DV SSL 证书，接入域名后自动申请，不需要额外操作。如果 www 也需要扫码 HTTPS，申请时勾选多域名即可。

Q：PaperMod 怎么加备案号？

在 layouts/partials/footer.html 里覆盖默认模板。PaperMod 的默认 footer 位于 themes/PaperMod/layouts/partials/footer.html，把内容复制过来，底部追加备案信息。Hugo 发现项目 layouts/ 下同名文件会优先用你的，不会动主题原文件。

Q：文章更新后旧页面能看到吗？

能看到。Hugo 构建时 CSS/JS 文件名含内容 hash，新版本文件名不同。旧文件还在 COS 上，EdgeOne 缓存里旧的 HTML 引用旧 JS——所以 deploy 后加了一步 CDN 刷新。

Q：COS 默认域名能被直接访问吗？

取决于桶权限。如果你设了私有读写+EdgeOne 私有访问授权，直接打 COS 默认域名会 403。顺手加 Referer 白名单可以多做一层防护。

Q：为啥不用 Cloudflare Pages / Vercel？

Cloudflare Pages 免费 500 次/月构建，Vercel 免费 6000 分钟/月。两家托管在国内的访问稳定性时好时坏——不是产品不行，是物理距离在那儿。腾讯云 COS + EdgeOne 面向国内用户，延迟 <50ms，在线率有 SLA。如果你的受众主要在海外，那 Cloudflare Pages 反倒更合适。

Q：文章多了以后构建和上传会变慢吗？

Hugo 官方的基准测试数据：5000 篇文章的站点，hugo build 在 1 秒内完成。瓶颈在上传：os.walk() 顺序串行，文件数到几千时可以考虑用 ThreadPoolExecutor 并行化上传。目前几十个文件串行够用。

写在最后

整个过程踩的最大坑是 EdgeOne 的「私有访问授权」和「公有读桶」的组合——文档里散落在不同页面，没有明确的「桶公有读时不要开私有访问授权」的警告。这篇记录把配置关系理成表格，方便以后查。

不用管服务器、不用打安全补丁、不用半夜被告警吵醒——COS 存文件，EdgeOne 扛流量，GitHub Actions 管发布。代价是没法跑动态内容（评论、登录、后台）。如果你需要这些，WordPress + 云服务器或者 Hugo + Serverless 评论更适合。

如果你也在搭类似的个人博客，上面的 deploy.yml 可以直接拿走用，改个 bucket 名字就行。

公司 Jira Data Center v10.3.3 集群的共享存储（NFS）跑在一块 7.8TB 的企业级 NVMe SSD 上，挂载路径 /data，实际数据量 7.0TB——全是 Jira 附件，不含数据库。

要腾出这块 SSD 给别的业务，替换盘是一块 45.5TB 机械硬盘（/dev/sda，未初始化）。要求在下一个工作日 9:00 前完成迁移，尽可能减少停服时间。

集群拓扑

10.177.100.25  Nginx (反向代理/负载均衡)
       │
       ├──→ 10.177.100.26  Jira Node 1
       └──→ 10.177.100.27  Jira Node 2
                │                      │
                ├──→ 10.177.100.28  MySQL 主
                ├──→ 10.177.100.29  MySQL 从
                │
                └──→ 10.177.100.30  NFS Server  ← 本次迁移对象

所有 IP 为企业内网地址，仅运维团队可达。

存储现状

迁移前的磁盘布局：

vdb  7.8T  NVMe SSD  ── vdb1  ext4  /dev/vdb1  →  /data   (7.0T 已用)
sda  45.5T HDD       ── 未分区，未格式化

迁移后的目标布局：

vdb  7.8T  NVMe SSD  ── 腾出
sda  45.5T HDD       ── sda1  ext4  /dev/sda1  →  /data   (7.0T 已用)

机械盘容量是 NVMe 的近 6 倍，写入速度约 110~140 MB/s——这是全流程的硬瓶颈。

方案选型

三选一，选了停服 rsync 一遍。

理由是 /data 目录下只有 Jira 附件、索引缓存等静态文件，不含写入中的数据库。停服后数据完全冻结，不存在 rsync 过程中文件被修改导致不一致的问题。7.0TB 数据，机械盘顺序写入 110+ MB/s，数学上 10~14 小时能跑完，停服窗口 24 小时绰绰有余。

没有用 dd。dd 会复制整块 7.8TB 盘（含空闲空间），额外消耗约 1 小时且浪费目标盘空间。rsync 只传实际文件，且参数 -aHAX 能完整保留软链接、硬链接、ACL 和扩展属性。

完整操作记录

所有命令在 NFS Server（10.177.100.30，root 用户）上执行。

第一步：开 tmux 防断连

tmux new -s jira-migration

SSH 连接意外断开时，tmux attach -t jira-migration 恢复会话。

第二步：停服

# 停 Jira 所有节点
systemctl stop jira

# 确认 /data 无进程占用
lsof +D /data 2>/dev/null

第三步：sda 分区与格式化

# GPT 分区表 + 单分区
parted /dev/sda --script mklabel gpt
parted /dev/sda --script mkpart primary ext4 0% 100%

# ext4 格式化，-m 0 不给 root 预留空间
mkfs.ext4 -m 0 -L jira-data /dev/sda1

-m 0 是 45TB 大容量盘的关键参数。默认 -m 5 会预留 5% 给 root，45.5TB × 5% = 2.3TB 浪费。NFS 共享盘不需要这层保护，-m 0 全部给数据。

第四步：执行迁移

mkdir -p /mnt/sda1
mount /dev/sda1 /mnt/sda1

# 核心传输命令
rsync -aHAX --info=progress2 --numeric-ids /data/ /mnt/sda1/

参数逐项说明：

第五步：实际耗时记录

实际耗时约 18 小时 22 分钟，平均速度 111 MB/s。比预估的 10-14 小时慢，原因是 Jira 附件目录中夹杂数十万个小文件（图标、缩略图、日志片段），随机寻道拉低了机械盘的实际写入吞吐。

第六步：校验

# 数据量对比
du -sh /data /mnt/sda1
# 两边均为 7.0T

# 文件数对比
find /data -type f | wc -l
find /mnt/sda1 -type f | wc -l
# 两边一致

第七步：切换挂载

# 卸载旧盘
umount /data

# 挂载新盘
mount /dev/sda1 /data

# 更新 fstab
cp /etc/fstab /etc/fstab.bak.$(date +%Y%m%d)
blkid /dev/sda1
# UUID=a1b2c3...  记录这个值

vi /etc/fstab
# 删除 vdb 那行，添加：
# UUID=a1b2c3...  /data  ext4  defaults,nofail  0  2

第八步：启动与排错

# 重启 NFS 服务（挂载点切换后 NFS 需要刷新文件句柄）
exportfs -ra && systemctl restart nfs-server

# 启动 Jira
systemctl start jira

Jira 启动后报错：

JIRA couldn't create the jira.home directory
Ensure JIRA has permission to create and write to the
jira.home directory /data/jirasoftware/jira-home/shared_home.

原因：NFS 内核模块缓存了旧 vdb1 的文件句柄，Jira Node 在挂载点切换后看到的仍是旧设备。exportfs -ra 刷新了 NFS 导出表，但 Jira Node 的 NFS 客户端缓存未清理。

解决：重启 Jira Node 1 和 Node 2，强制刷新 NFS 客户端缓存。

# 在 10.177.100.26 和 10.177.100.27 上执行
reboot

重启后 Jira 正常启动，附件可访问，集群状态恢复。

日常运维速查

以下命令在日常运维中高频出现，按场景归类备查。

Jira 启停

# 启动
systemctl start jira

# 停止
systemctl stop jira

# 或者用 Jira 自带脚本
/data/jirasoftware/jira/bin/start-jira.sh
/data/jirasoftware/jira/bin/stop-jira.sh

MySQL 启停

systemctl start mysql
systemctl stop mysql
systemctl restart mysql

NFS 服务

systemctl start nfs-server
systemctl stop nfs-server
systemctl restart nfs-server

# 刷新导出表（修改 /etc/exports 后必须执行）
exportfs -ra

# 查看客户端挂载情况
showmount -e 10.177.100.30

磁盘检查

# 查看挂载点与磁盘对应关系
lsblk

# 查看 /data 使用量
df -h /data

# 查看 /data 内容概览
du -sh /data

关键配置文件位置

注意事项

1. 停服前做最终状态确认。生产环境停服不是小事。除了 systemctl stop jira，还要 lsof +D /data 确认无一进程占用，NFS 客户端缓存可能导致静默写入。

2. rsync 源路径末尾斜杠是坑。/data/ 和 /data 的区别是一层目录结构。用错了会让目标盘里塞一个多余的 /data/ 子目录，Jira 的 jira.home 配置指向的路径就找不到了。

3. -m 0 不是默认参数。mkfs.ext4 不给 -m 参数时默认预留 5% 给 root。45TB 上的 5% 是 2.3TB——大到摸得着。NFS 数据盘生产用途明确，不需要反碎片化保护，全部空间给业务数据。

4. NFS 切换后必须刷新两端缓存。服务端 exportfs -ra 刷新导出表，客户端重启或重新挂载清除内核 NFS 句柄缓存。只做一端的效果是 Jira 无法写入 shared_home 目录。

5. Jira Data Center 的 shared_home 路径不能变。cluster.properties 里硬编码了 /data/jirasoftware/jira-home/shared_home。迁移时目标盘挂载点必须完全一致（/data），否则需要停机修改集群配置并重启所有节点。

6. 回滚路径要保持到验证结束。迁移完成后 vdb 上的数据不要立刻清除。等 Jira 跑 2~3 个工作日，确认附件上传、全文搜索、集群同步都没问题，再考虑回收旧盘。遇到问题只需 umount /data && mount /dev/vdb1 /data && systemctl start jira 即可回退。

小结

从一块 NVMe SSD 到一块机械盘，迁移 7TB Jira 附件数据，核心就一条 rsync -aHAX --info=progress2 --numeric-ids /data/ /mnt/sda1/。参数选对了，数据属性一件不少；停服窗口估准了，团队沟通在先，操作过程没有意外。

机械盘写入带宽是硬天花板——111 MB/s 对 7TB 来说跑 18 小时无可避免。真正把时间从"超过 24 小时"压缩到 18 小时的是文件系统参数：-m 0 省了 2.3TB 无用写入，GPT 单分区省了 MBR 扩展分区链的开销。这些微调单独看都不起眼，叠在一起就是停服窗口能不能按时交付的差距。