[{"content":"1 需求背景 公司有一台内网服务器（btk-acloud，Ubuntu 24.04 LTS），上面 /data/baic_n60/ 目录里存着团队的共享文件。内部同事需要随时通过浏览器访问这些文件——浏览目录、下载。\n这台机器有几个约束：\n约束项 详情 网络 无外网——apt 源走内网镜像，但 pip/npm/git clone 全部不可用 Python 系统预装 Python 3.12.3，但 PEP 668 禁止 pip 全局安装包 访问路径 通过跳板机 10.10.0.4 转发才到 112.31.22.151:3022 数据量 45.5TB 机械盘，/data 已用 7.5TB 并发 团队规模 10-20 人，偶尔同时下载大文件 不允许在这个不带外网的机器上折腾 pip install、uv pip install、docker pull、或者 apt-get install nginx 拉一堆依赖——这台机器不是开发机，是生产服务器，不能为一个小需求破坏系统 Python 环境。\n2 环境拓扑 [ 同事浏览器 ] │ ↓ 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 连接命令：\nsshpass -p \u0026#39;\u0026lt;password\u0026gt;\u0026#39; ssh \\ -o \u0026#34;ProxyCommand ssh -i ~/.ssh/id_ed25519 herui@10.10.0.4 -W %h:%p\u0026#34; \\ -p 3022 sup1whu@112.31.22.151 由于内网同事通过 HTTP 请求直接打到目标机的 19527 端口，这里不需要 Nginx 反代。服务直接监在 0.0.0.0:19527 即可。\n3 核心架构决策 3.1 为什么不用 Flask / FastAPI / Django 装不上。没有外网，pip 不可用。apt-get install python3-flask 也不行——Debian 系的 Python 包命名风格和 pypi 不一致，很多现代 Web 框架没有 apt 打好的包。\n3.2 为什么不用 Nginx autoindex apt-get install nginx 理论上可以，但对一台 45TB 数据盘的生产服务器，装 nginx 意味着多一个进程、多一套配置、多一个攻击面。这个文件服务器的需求很简单——列目录、下载文件——Python 标准库完全够用。\n3.3 选型对比 方案 依赖 部署复杂度 功能覆盖 安全风险 Nginx autoindex apt nginx 中（需配置 server block） 完整（但无定制 UI） Nginx CVE Python Flask + pip 包 pip + 外网 高（需要 venv） 完整 依赖链 Python 标准库 http.server 无 低 完整 仅 Python 运行时 busybox httpd apt busybox 低 弱（无目录列表样式） 低 Python 标准库方案对这台「无外网 + 生产环境 + PEP 668」的机器是最优解。\n3.4 模块选择：ThreadingHTTPServer Python 3.12 标准库自带了两个 HTTP 服务器：\n类 并发模型 适用场景 http.server.HTTPServer 单线程，请求排队 开发调试 http.server.ThreadingHTTPServer 每请求一个线程 生产环境 10-20 人团队，ThreadingHTTPServer 够用。不需要引入 asyncio 或者 socketserver.ForkingMixIn——多线程在这个并发量级下足够。\n4 代码实现逻辑 完整代码约 350 行，零外部 import。只用了 Python 3.12 自带的这些模块：\nimport 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 内：\ndef translate_path(self, path): path = urllib.parse.unquote(path.split(\u0026#34;?\u0026#34;)[0].split(\u0026#34;#\u0026#34;)[0]) rel = path.lstrip(\u0026#34;/\u0026#34;) 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, \u0026#34;\u0026#34;) # 越界→返回空路径→404 return fs_path 这里三处调用 os.path.realpath 是为了处理符号链接绕过——os.path.normpath 只做字符串规范化，不解析软链接。os.path.realpath 把路径解析到真实的 inode，再比较。\n4.3 目录列表：HTML 模板渲染 list_directory() 的逻辑：\nos.scandir(path) 遍历目录（比 os.listdir + os.stat 快，一次系统调用同时拿到文件名和 stat） 目录和文件分两组，各自按名称排序（不区分大小写），目录排前面 每个条目生成 \u0026lt;tr\u0026gt;：图标（📁/📄）、带链接的文件名、人类可读大小、日期 用 HTML_TEMPLATE.format() 填充整页 文件名列没有设固定宽度、没有 text-overflow: ellipsis。CSS 用了 word-break: break-all 和 overflow-wrap: anywhere——文件名多长都能完整显示。这是最早版本用 min-width: 0 + word-break 的组合，测试过 80+ 字符的文件名不会溢出也不换行错乱。\n4.4 文件下载：强制下载头 self.send_header( \u0026#34;Content-Disposition\u0026#34;, f\u0026#39;attachment; filename=\u0026#34;{urllib.parse.quote(fname)}\u0026#34;\u0026#39; ) 只要请求的是文件（不是目录），就加 Content-Disposition: attachment。不管浏览器能不能内联打开（PDF、图片、txt），都给下载。这是团队明确的需求——这些文件本身就是用来下载的，不是在线预览的。\n4.5 深色/浅色切换 用 CSS 自定义属性（--bg、--text 等）+ data-theme 属性切主题：\n:root { --bg: #ffffff; --text: #1a1a1a; ... } [data-theme=\u0026#34;dark\u0026#34;] { --bg: #0f172a; --text: #e2e8f0; ... } JS 就两件事：\n页面加载时读 localStorage.getItem('baic-theme')，设置初始主题 点击开关时切 data-theme 属性 + 更新 localStorage 不需要 cookie、不需要后端 session、不需要 CSS 预处理。8 行 JavaScript 解决问题。\n5 部署步骤 5.1 上传代码到目标机 通过跳板机 SCP 把本地写好的 baic-server.py 推到目标机：\nsshpass -p \u0026#39;\u0026lt;password\u0026gt;\u0026#39; scp \\ -o \u0026#34;ProxyCommand ssh -i ~/.ssh/id_ed25519 herui@10.10.0.4 -W %h:%p\u0026#34; \\ -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 输出：\nBiTECH File System running on http://0.0.0.0:19527/ Serving: /data/baic_n60 Press Ctrl+C to stop. 在另一台能访问目标机的内网机器上：\ncurl -sI http://10.177.100.30:19527/ # HTTP/1.0 200 OK # Content-Type: text/html; charset=utf-8 Ctrl+C 停掉手动进程，确认端口释放：\nss -tlnp | grep 19527 # 应该无输出 5.3 配置 systemd 用户服务 服务文件路径：~/.config/systemd/user/baic-files.service\n[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 每个参数的含义：\n参数 值 说明 Type simple 服务启动即视为就绪。Python 脚本前台运行，不需要 forking ExecStart /usr/bin/python3 ... 绝对路径。不用 python3 是因为 systemd 不读 shell PATH Restart always 无论退出码是什么都重启。进程 crash、OOM kill、手动 kill 都会自动拉起来 RestartSec 5 等 5 秒再重启。防止疯狂重启循环刷日志 WorkingDirectory /home/sup1whu Python 进程的 CWD。脚本本身用了绝对路径，但以防万一 5.4 启用 linger + 启动服务 用户级 systemd 服务默认只在用户登录时运行。这个机器没有图形界面、没有常驻登录会话，需要开启 linger 让服务在系统启动时就起：\n# 允许 sup1whu 用户在系统启动时自动起服务（不需要登录会话） sudo loginctl enable-linger sup1whu # 重载 systemd 用户实例、启用服务 systemctl --user daemon-reload systemctl --user enable baic-files.service systemctl --user start baic-files.service 三步的区别：\n命令 作用 daemon-reload 让 systemd 重新读 .service 文件 enable 写入启动链（default.target.wants/），但不立即启动 start 立即启动。如果已经在跑，start 是幂等的 验证：\nsystemctl --user status baic-files --no-pager 输出示例：\n● 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 只在有请求时才起线程，平时就一个主线程。\n5.5 功能验证 用 curl 跑了 7 项测试：\n# 测试项 URL 预期 结果 1 根目录 GET / 200 + HTML 目录列表 ✅ 2 子目录 GET /subdir1/ 200 + 子目录内容 ✅ 3 长文件夹名 GET /very_long_folder_name_test_2026_Q3/ 200 + 空目录提示 ✅ 4 文件下载 GET /test_file_1.txt 200 + Content-Disposition ✅ 5 长文件名下载 GET /report_2026_...very_long_name.pdf 200 + 正确文件名 ✅ 6 嵌套文件 GET /subdir1/nested.txt 200 ✅ 7 404 GET /nonexistent 404 ✅ 6 运维管理常用命令 6.1 日常操作 操作 命令 查看服务状态 systemctl --user status baic-files --no-pager 查看最近日志 journalctl --user -u baic-files -n 50 --no-pager 实时跟踪日志 journalctl --user -u baic-files -f 重启服务 systemctl --user restart baic-files 停止服务 systemctl --user stop baic-files 禁用开机自启 systemctl --user disable baic-files 查看 linger 状态 loginctl show-user sup1whu | grep Linger 查看监听端口 ss -tlnp | grep 19527 查看进程树 ps auxf | grep baic-server 查看连接数 ss -tn state established '( sport = :19527 )' | wc -l 检查错误日志 journalctl --user -u baic-files -p 3 --no-pager 6.2 更新代码流程 # 1. 本地修改 baic-server.py，测试通过 python3 /tmp/baic-server.py \u0026amp; curl -sI http://127.0.0.1:19527/ kill %1 # 2. 通过跳板机推到目标机 sshpass -p \u0026#39;\u0026lt;password\u0026gt;\u0026#39; scp \\ -o \u0026#34;ProxyCommand ssh -i ~/.ssh/id_ed25519 herui@10.10.0.4 -W %h:%p\u0026#34; \\ -P 3022 /tmp/baic-server.py sup1whu@112.31.22.151:~/baic-server.py # 3. 重启服务（systemd 用新代码） sshpass -p \u0026#39;\u0026lt;password\u0026gt;\u0026#39; ssh \\ -o \u0026#34;ProxyCommand ssh -i ~/.ssh/id_ed25519 herui@10.10.0.4 -W %h:%p\u0026#34; \\ -p 3022 sup1whu@112.31.22.151 \\ \u0026#34;systemctl --user restart baic-files \u0026amp;\u0026amp; systemctl --user status baic-files --no-pager\u0026#34; 不要直接在目标机上用 vim 改代码然后 systemctl --user restart。目录 /data/baic_n60/ 是生产数据，vim 出错了没有 git 回滚。\n6.3 磁盘监控 检查项 命令 磁盘使用 df -h /data 大目录排查 du -sh /data/baic_n60/* | sort -rh | head -20 文件数量统计 find /data/baic_n60 -type f | wc -l 最近修改的文件 find /data/baic_n60 -type f -mtime -7 7 踩坑记录 7.1 PEP 668：externally-managed-environment 最开始想在目标机上 pip install flask，报错：\nerror: externally-managed-environment × This environment is externally managed Ubuntu 24.04 默认的 Python 3.12 开启了 PEP 668 保护——禁止 pip 往系统 site-packages 装东西。这是好事，保护系统 Python 不被破坏，但意味着不能走常规的 pip 安装路线。\n绕不过去：\npip install --break-system-packages：语法上能绕过 PEP 668，但没网，pypi.org 连不上 python3 -m venv + pip：同样卡在外网上 apt-get install python3-flask：Debian/Ubuntu 没有 Flask 的 apt 包 回到标准库。http.server.ThreadingHTTPServer 在这个并发量级下够了。\n7.2 systemd 用户服务不启动 systemctl --user enable baic-files 成功后重启机器服务没起来。检查：\nloginctl show-user sup1whu | grep Linger # Linger=no 用户服务在 session 级别启动。没有 linger 的情况下，WantedBy=default.target 不会在系统启动时触发——因为 default.target 对于用户实例，只有在用户首次登录时才启动。\n修复：sudo loginctl enable-linger sup1whu，下次重启服务就自动起来了。这个行为在 systemd 官方文档 logind.conf(5) 里有说明，但不踩这个坑不会注意到。\n7.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 用绝对路径。\n7.4 从临时进程切换到 systemd 时的端口冲突 手动 python3 ~/baic-server.py \u0026amp; 启动的进程在后台跑着，后来 systemctl --user start baic-files 也起了。两个进程抢 19527 端口，后者报 Address already in use。\nsystemd 的 Restart=always 会不断重试，日志里刷了一串失败。手动 kill 掉旧进程后 systemd 自动恢复。\n先停手动进程、再起 systemd。如果已经乱了，pkill -f baic-server.py 清掉所有残留，systemd 会在下一个 RestartSec 后自动拉起来。\n8 最终状态一览 项目 值 服务名称 baic-files.service 端口 19527 监听地址 0.0.0.0 数据目录 /data/baic_n60/ 磁盘 /dev/sda1 (46TB, 17% 已用) 系统 Ubuntu 24.04.1 LTS, kernel 6.17.0-35 Python 3.12.3（标准库，零 pip 包） systemd 用户级服务 + linger 开机自启 内存占用 ~10MB 并发模型 ThreadingHTTPServer (per-request thread) 前端功能 深色/浅色切换、面包屑导航、长文件名完整展示、日期+大小列 安全 路径穿越防护（realpath + commonpath）、Content-Disposition 附件下载 整个部署从零到 production-ready 花了一个小时——其中 30 分钟在调研「无外网 + PEP 668」环境下的可行方案，20 分钟写代码，10 分钟部署 + 验证。\n","permalink":"https://raysre.com/posts/python-file-server-deployment/","summary":"\u003ch2 id=\"1-需求背景\"\u003e1 需求背景\u003c/h2\u003e\n\u003cp\u003e公司有一台内网服务器（\u003ccode\u003ebtk-acloud\u003c/code\u003e，Ubuntu 24.04 LTS），上面 \u003ccode\u003e/data/baic_n60/\u003c/code\u003e 目录里存着团队的共享文件。内部同事需要随时通过浏览器访问这些文件——浏览目录、下载。\u003c/p\u003e","title":"零依赖 Python 文件服务器部署：从跳板 SSH 到 systemd 生产化的全流程"},{"content":"写在前面 手上有两张招行卡，一张借记卡一张信用卡。最近整理快捷支付授权列表的时候发现，不知不觉绑了十几个平台——有些完全想不起来什么时候授权的。\n仔细一想，每个平台都能从我的卡里扣钱，但我对它们的安全机制几乎一无所知。唯一的判断标准是「大厂，应该没事吧」。\n花了一周时间逐个查这些平台背后的持牌机构、央行处罚公示、安全白皮书和公开披露的安全事件。查下来的结果让我挺意外的——差距远比我预想的大。Apple Pay 和云闪付用的是同一套硬件级 Token 方案，而拼多多 App 刚被 Google 因为利用 Android 0-day 漏洞收集用户数据从 Play 商店全线撤下。这中间差了不止一个量级。\n这篇文章把查到的东西整理出来，方便自己以后参考。数据来源都在文中标了，主要是央行行政处罚公示、移动支付网公开统计和澎湃新闻/央广网的报道。有错的欢迎指正。\n一、决定安全的三个技术分水岭 分析完 17 个平台后发现，真正拉开安全差距的不是公司名气，是三个硬指标：\n第一个，有没有 Token 化。 Token 化意味着平台和商户都不接触你的真实银行卡号，只用一个受限的虚拟令牌替代。这个令牌可以限设备、限商户、限单次。没有 Token 化的平台，你的卡号直接存在它们的系统里——你对它的信任本质上就是赌它的数据库不会被拖走。\n第二个，风控引擎的成熟度。 关键指标是交易量 × 拦截率。支付宝的 CTU 每秒处理 40 万笔交易，这是十几年积累下来的模型能力。腾讯天御借助微信社交关系图谱做异常检测，把资金损失率压到了业内罕见的水平。而一些中小支付机构的风控，技术上约等于黑名单匹配加简单规则。\n第三个，有没有安全事件前科。 这是最直白的信号。一次严重安全事件，暴露的不是一个 bug，而是一家公司在安全工程和合规文化上的系统性缺陷。携程 2014 年的日志明文记录 CVV 码，拼多多 2023 年把安全能力用在攻击用户隐私上——这类记录不会因为「已经整改了」就应该被忽略。\n下面是 17 个平台在这三个维度上的全量对照。\n二、技术框架总览 2.1 核心安全机制对比 平台 Token化方案 风控引擎 硬件安全 生物识别 Apple Pay DAN(设备账户号)+动态安全码 不参与,由发卡行处理 Secure Element独立芯片 Touch ID / Face ID 云闪付 EMVCo Token(国际标准) 前防-中控-后偿三阶段 eSE / TEE双模支持 指纹/人脸(手机厂商提供) 银联在线支付 不适用(直连发卡行) 发卡行直连验证 不涉及客户端硬件 无(四重密码验证) 支付宝 AT Token体系(自有标准) CTU引擎,40万笔/秒 无独立芯片,软件实现 3D活体检测,误识率\u0026lt;10⁻⁹ 财付通 财付通Token(自有标准) 天御引擎,社交图增强 无独立芯片,国密SM2/SM4 HSM 指纹/人脸(微信App层) 京东支付 京东Token(自有标准) 电商+物流数据融合风控 无独立芯片 指纹/人脸(京东App层) 抖音支付 字节Token(自有标准) 字节AI平台支撑 无独立芯片 指纹/人脸(抖音App层) 美团支付 美团Token(自有标准) 场景+位置数据风控 无独立芯片 指纹/人脸(美团App层) 小米钱包(NFC) 银联Token(走Mi Pay通道) 银联+发卡行处理 eSE芯片(NFC机型) 指纹 小米钱包(线上) 捷付睿通自有通道 自建风控 无独立芯片 指纹/人脸(MIUI层) 翼支付 电信自有Token 运营商数据+电信天翼云 无独立芯片 指纹/人脸 和包支付 中移自有Token 运营商数据+中移能力 无独立芯片(NFC除外) 指纹/人脸 拼多多支付 付费通自有Token 基础风控 无独立芯片 无独立生物识别 携程支付 东方汇融自有Token 旅游场景基础风控 无独立芯片 无独立生物识别 通联支付 自有Token(面向商户) B端商户风控为主 无独立芯片 不面向个人用户 富友支付 自有Token(面向商户) B端商户风控为主 无独立芯片 不面向个人用户 苏宁支付 易付宝自有Token 电商场景基础风控 无独立芯片 指纹/人脸 唯品支付 唯品会自有Token 电商场景基础风控 无独立芯片 指纹/人脸 2.2 加密标准与合规认证 平台 加密标准 ISO认证 PCI-DSS 国密算法 数据本地化 Apple Pay AES-256, ECC ✓ ✓(通过银联间接) ✗ 中国大陆iCloud 云闪付 EMVCo标准, RSA-2048 ISO 27001 ✓ SM2/SM4 ✓(全部境内) 支付宝 RSA-2048, AES-256 ISO 27001/27701 ✓ SM2/SM4 ✓(全部境内) 财付通 RSA-2048, AES-256 ISO 27001 ✓ SM2/SM4 ✓(全部境内) 京东支付 RSA-2048, AES-256 ISO 27001 ✓ 部分支持 ✓(全部境内) 抖音支付 RSA-2048 未公开 ✓ 未公开 ✓(全部境内) 美团支付 RSA-2048 未公开 ✓ 未公开 ✓(全部境内) 小米钱包 RSA-2048, 银联NFC标准 未公开 ✓ 部分支持 ✓(全部境内) 翼支付 国密SM系列 ISO 27001 ✓ SM2/SM4 ✓(全部境内) 和包支付 国密SM系列 未公开 ✓ SM2/SM4 ✓(全部境内) 拼多多支付 基础RSA 未公开 未公开 未公开 ✓(全部境内) 携程支付 基础RSA 未公开 ✓(2014年后补做) 未公开 ✓(全部境内) 通联支付 RSA/AES 未公开 ✓ 未公开 ✓(全部境内) 富友支付 RSA/AES 未公开 ✓ 未公开 ✓(全部境内) 苏宁支付 基础RSA 未公开 ✓ 未公开 ✓(全部境内) 唯品支付 基础RSA 未公开 ✓ 未公开 ✓(全部境内) 三、监管处罚记录 2025 年全年，人民银行及各地分支机构合计对支付机构开出 80 张罚单，罚没金额合计约 2.88 亿元，较上年度（剔除对银联股份的处罚）增长超过 50%。其中支付结算领域 69 张（2.62 亿元）、综合罚单 7 张（2287 万元）、反洗钱领域 4 张（338 万元）。\n这仅是一年的数据。下面是与本文相关的平台和其持牌机构被处罚的核心记录。\n3.1 监管处罚明细 平台 持牌机构 处罚文件编号 时间 罚款金额 违规事由 支付宝 支付宝(中国)网络技术有限公司 银罚决字【2023】26-33号 2023.07 罚没30.6亿元（没收8.31亿+罚款22.31亿） 7项违法：违反支付结算管理规定、违反反洗钱规定、违反金融消费者权益保护规定等 财付通 财付通支付科技有限公司 央行同期公示 2023.07 罚没29.9亿元（没收5.66亿+罚款24.27亿） 违反支付结算管理规定、反洗钱义务等 京东支付 网银在线(北京)支付科技有限公司 银京罚决字〔2025〕54-55号 2025.08 罚没约962万元（没收219万+罚款743万），总裁另罚33万 10项违法：未落实商户实名制、支付接口管理不规范、违规非同名划转、备付金违规等 京东支付 网银在线(北京)支付科技有限公司 银京罚决字〔2025〕24号、25号 2025.01 约101.7万元（含风控负责人罚5.13万） 反洗钱违规：未履行客户身份识别义务、未报送大额/可疑交易报告 小米钱包 捷付睿通(内蒙古)支付股份有限公司 蒙银罚决字〔2026〕3号 2026.05 167.1万元 违反反洗钱管理规定 通联支付 通联支付网络服务股份有限公司 历次处罚（多地分行公示） 2016-2025 历史累计超千万元 违反银行卡收单业务规定、反洗钱违规、涉非法集资关联案件 富友支付 上海富友支付服务股份有限公司 历次处罚（上海分行等多地） 2017-2025 多次被罚，单次最高数百万 反洗钱违规、数据报送不合规、商户管理违规 关于网银在线（京东支付）：六年累计已被央行处罚五次，累计罚没超过 4200 万元。2025 年两次罚单间隔仅 7 个月，违规类型覆盖支付结算、反洗钱、备付金管理等几乎所有监管领域的常见违规项。黑猫投诉平台上有超过 3000 条「不知情扣款」相关投诉。\n3.2 行业处罚趋势 指标 2024年 2025年 变化 支付机构罚单总数 ~50张 80张 ↑60% 罚没总金额 ~1.8亿(剔除银联处罚) 2.88亿 ↑超50% 超千万元罚单数 3张 5张 ↑67% 支付结算领域罚没金额 9901.74万元 2.62亿元 ↑164% 数据安全/网络安全罚单 0张 首次出现（人保支付罚104万等） 新增领域 有效支付牌照总数 ~175张 163张 12张注销 来源：移动支付网《2025年中国人民银行支付机构处罚分析》\n四、安全事件记录 监管罚单反映的是合规能力，安全事件反映的是工程能力。两者加在一起才能判断一个平台到底值不值得信任。\n平台 事件类型 时间 细节 拼多多 恶意代码被下架 2023.03 Google安全团队发现拼多多App利用Android未公开漏洞(0-day)绕过用户授权，读写其他App私有数据、修改系统设置。随后被Google Play全线撤下数月。不是bug——是利用漏洞主动攻击用户隐私 拼多多 违规收集个人信息 2019-2023 工信部、网信办多次通报「违规收集个人信息」「超范围收集个人信息」「强制用户使用定向推送功能」 携程 支付日志明文泄露CVV 2014.03 乌云漏洞平台(WooYun)曝出携程支付系统日志直接记录了用户银行卡号、CVV安全码、有效期——全部明文。PCI-DSS标准明确禁止在任何情况下存储CVV，加密也不行 携程 用户数据泄露 2015 再次被曝用户数据泄露事件 京东 数据泄露 2016 12GB用户数据包外泄，含支付相关信息 唯品会 用户数据泄露 2016 包含支付信息的用户数据泄露 美团 \u0026ldquo;杀熟\u0026quot;争议 2017-2024 用户反复曝光同一商品对不同用户显示不同价格，侧面印证内部用户画像与数据分析能力极强 支付宝 蚂蚁集团被约谈后重组 2020-2023 上市暂停、业务整改、花呗借呗品牌隔离。非安全事件，但反映了数据治理的重大变化 五、隐私策略对比 支付安全和隐私保护是两件事。一个平台可以技术上很安全（不丢钱），同时隐私上很危险（数据被用于你不愿意的用途）。\n平台 商业模式依赖用户数据程度 支付数据是否用于推荐/广告 跨业务数据打通 第三方可审计性 Apple Pay 极低(硬件+服务盈利) 否,Apple不追踪交易 否 否(封闭系统,但数据量少) 云闪付 极低(清算+公共服务) 否,仅用于清算和反欺诈 否(仅银联体系) 央行监管,无需第三方 支付宝 中等(信贷/保险/理财) 官方承诺隔离,无第三方审计 是(蚂蚁集团内各业务) 否 财付通 中等(社交生态变现) 官方承诺隔离,无第三方审计 是(与微信社交数据同属一家) 否 京东支付 较高(电商+金融) 与电商消费数据关联 是(京东科技内多业务) 否 抖音支付 高(内容推荐+电商) 字节生态系统高度集中 是(视频/社交/电商/支付) 否 美团支付 高(本地生活全链路) 外卖/酒店/到店数据与支付打通 是(完整的LBS消费画像) 否 小米钱包 较高(硬件+IoT+电商) MIUI设备行为+IOT+商城消费 是(系统级权限) 否 翼支付 中高(运营商数据) 实名/位置/轨迹/通话+支付 是(运营商级数据) 否 和包支付 中高(运营商数据) 实名/位置/轨迹/通话+支付 是(运营商级数据) 否 拼多多支付 高(社交电商) 社交裂变+消费+支付全部打通 是(拼多多App内全链路) 否 携程支付 中高(旅游+金融) 出行/住宿/消费高度关联 是(携程内多业务) 否 通联支付 低(主要B端商户) 不面向个人消费者 否(B端独立) 可选(商户端) 富友支付 低(主要B端商户) 不面向个人消费者 否(B端独立) 可选(商户端) 苏宁支付 较高(零售+金融) 苏宁零售生态内打通 是 否 唯品支付 中等(品牌特卖电商) 电商消费+支付关联 是 否 六、逐平台深度分析 第一梯队：几乎无懈可击 Apple Pay Apple Pay 的安全模型和所有其他平台都不同。它不存储你的银行卡号，不追踪你的交易，风控也完全交给发卡行——Apple 自己只负责硬件和身份验证。\n核心机制：当你把招行卡添加到 iPhone 的 Wallet App 时，系统通过银联向招行发起验证请求。招行验证你的身份后，生成一个唯一的设备账户号（DAN：Device Account Number），直接写入 iPhone 的 Secure Element 芯片里。\nSecure Element 是一块独立于主 CPU 的硬件安全芯片。iOS 系统和任何 App 都读不到里面存了什么。物理拆解会触发芯片自毁。每一笔支付在 Secure Element 内部生成一次性的动态安全码，和 DAN 配对使用。即使有人截获了这笔交易的数据，也无法用于第二次支付。\nApple 能做到这么干净，本质原因是它的商业模式不靠支付数据变现。硬件利润、App Store 抽成和服务订阅已经极端丰厚了，没有必要为了多赚一点去碰用户的交易隐私。在这个行业里，商业模式天然决定了隐私保护的上限。\n云闪付 云闪付走的是国际标准的 EMVCo Token 化体系——和 Visa、Mastercard 的 Token 服务同一套规范。银联的角色是中国银行卡清算组织，直连央行。这意味着它的数据只用于清算和反欺诈，没有商业变现压力。你不会担心银联拿你的消费记录去做推荐算法。\n风控分三段：绑卡时用 Token 替代真实卡号（前防），交易中实时评估并及时拦截异常（中控），出了事只要用户无过错就全额赔付、没有赔付上限（后偿）。这个「无上限」承诺在中国第三方支付行业里是独一份的。\n如果说 Apple Pay 是借助硬件做到了安全性最优，那云闪付就是在监管位置和数据用途上的最优解——没有商业变现动机，就没有数据滥用的风险。\n银联在线支付 银联在线支付是传统的网关支付，不走第三方平台的账户体系。交易时需要同时输入完整卡号、取款密码、手机验证码和 CVV（四重验证），通过银联网关直连招行扣款。整个过程中间没有第三方机构持有你的账户信息。\n代价就是流程繁琐——每次都要手打一堆数字。日常小额用它不现实，但大额付款或对安全性有极端要求的时候，它是理论上最安全的选择。四个验证因子同时被泄露或截获的概率极低。\n第二梯队：成熟但各有隐忧 支付宝 支付宝的安全体系在全球支付机构里属于第一梯队。CTU（Creditable Transaction Unit）风控引擎对外公布的指标是每秒处理 40 万笔交易，背后的模型是一个深度学习神经网络加若干规则引擎的组合。2022 年支付宝在公开报告中披露过，全年拦截风险交易超过 200 亿次。\n几个具体技术点：\n3D 活体检测通过了国家金融科技认证中心认证，误识率低于十亿分之一（10⁻⁹）。照片、视频重放、3D 打印面具都能识别。 设备指纹采集了超过 100 个维度的硬件和软件特征——包括传感器特性、屏幕参数、字体列表。模拟器和多开环境会被直接拒绝，也可以检测出设备是否被 root 或越狱。 行为生物特征在后台静默运行——击键节奏、触屏压力曲线、滑动轨迹。你自己感觉不到，但换一个人用你的手机支付，模型能立刻捕捉到行为模式的变化。 从隐私角度看，支付宝数据用途的透明度不算高。蚂蚁集团虽然已完成整改，但其信贷（花呗借呗）、保险（相互宝/好医保）、理财（余额宝/蚂蚁财富）与支付数据本质上在一个生态内流转。如果我是招行用户，在支付宝上做日常支付可以接受，但不会让支付宝成为我唯一的支付入口。\n史上最大罚单：2023 年 7 月，央行对支付宝开出 银罚决字【2023】26-33 号 罚单，罚没合计 30.6 亿元（没收违法所得 8.31 亿 + 罚款 22.31 亿），涉及 7 项违法行为。同时蚂蚁集团也被穿透式处罚。这个金额是全球支付行业有史以来最高的单笔罚款。\n来源：澎湃新闻 / 央广网\n财付通（微信支付） 腾讯做支付安全有一个别人复刻不了的优势：社交图谱。\n财付通的风控系统叫「天御」，它在决策一笔交易是否可疑的时候，能参考的不只是交易本身的金额、时间、地理位置，还包括支付双方的社交关系、设备登录历史、位置变动轨迹。比如一个你从未联系过的账户突然向你发起大额转账，或者你的微信账号同时在两个相距 500 公里的设备上登录——天御能在毫秒级捕捉这种异常。\n效果反映在一个数字上：财付通的资金损失率在 2022 年压到了十五万分之一。这个数字在全球支付机构里都是顶尖的。\n2023 年 7 月与支付宝同期，财付通也被央行罚没 29.9 亿元（没收 5.66 亿 + 罚款 24.27 亿）。同样的压力测试下活下来的平台，内控合规至少是被强制矫正过的。\n真正的风险不在支付安全本身，而在隐私边界。微信支付和微信聊天是同一家公司运营的。虽然腾讯官方承诺「支付数据不用于广告推荐」，但没有第三方独立审计可以验证。作为用户，你只能选择信任这个承诺——或者不用。\n京东支付 先说好的：京东支付的风控利用了电商和物流数据的天然优势，事先的设备指纹采集、事中的实时评分、事后的离线审计——全链路反欺诈框架是完整的。\n再说具体的：它的持牌机构网银在线，六年被央行罚了五次。\n时间 文件编号 罚没金额 核心违规 2025.01 银京罚决字〔2025〕24号/25号 ~101.7万 反洗钱：未履行客户身份识别义务、未报送大额/可疑交易报告 2025.08 银京罚决字〔2025〕54-55号 约962万 10项违法：未落实商户实名制、支付接口不规范、违规非同名划转、备付金违规、未确保交易信息真实完整可追溯 2019-2024 多次 累计约3000万+ 支付结算违规、反洗钱违规 来源：移动支付网 / 腾讯新闻\n六年累计罚没超 4200 万元的持牌支付机构，技术和合规之间是割裂的。另外京东 2016 年发生过 12GB 用户数据泄露，黑猫投诉上还有 3000 多条「不知情扣款」的记录。我个人只在京东上买自营商品时用京东支付，其他地方一律走微信或支付宝。\n第三梯队：支付不算差，隐私让人担心 抖音支付 抖音支付本身的支付通道安全性不用太担心——2048 位 RSA 加密传输，央行持牌（合众易宝），字节跳动的 AI 能力能提供较强的异常检测。在抖音里买东西，用抖音支付还是用支付宝付钱，被盗刷的风险差异不大。\n问题全在隐私上。\n字节跳动的商业模式建立在深度学习用户行为之上。你用抖音刷视频、看直播、在商城下单、然后用抖音支付付款——所有这些行为数据完整地留在了同一套系统里。一个平台同时掌握你的内容消费偏好、社交互动记录和完整的支付交易明细。它说「支付数据与推荐系统隔离」，但没有第三方审计能验证。\n我自己的做法是：抖音买东西只走支付宝。虽然两种方式的支付安全差不多，但至少支付宝不会把支付数据和我的短视频观看记录放在一起。\n美团支付 和抖音的问题是同一类：不是支付不安全，是生态内数据太集中。外卖地址、到店消费、酒店入住、电影票预订，加上支付流水——这几乎是一个人的完整线下活动画像。\n技术上，美团的风控利用了场景数据的天然优势。一个长期在北京叫外卖的账号突然在深圳产生一笔凌晨酒店支付——这种异常信号对美团来说太容易捕捉了。但美团「杀熟」争议（不同手机、不同用户看到不同价格，反复被用户实测验证）也从侧面说明它的数据分析和用户画像能力极强。\n小米钱包 分两条路径看：\nNFC 闪付（Mi Pay）：走银联 Token 化通道，用手机 Secure Element 芯片存储，和 Apple Pay 原理一致。这部分的安全性取决于硬件，小米旗舰机的 eSE 方案是可靠的。 线上绑卡到小米钱包 App：走捷付睿通自有通道。捷付睿通是小米全资子公司，2026 年 5 月因「违反反洗钱管理规定」被央行内蒙古分行处罚，文件编号 蒙银罚决字〔2026〕3 号，罚款 167.1 万元。这已经是捷付睿通成立以来第四次被罚。 来源：移动支付网 / 中国经济网\n另外，MIUI 作为操作系统，在系统层面对用户设备拥有最高权限。硬件设备行为、IoT 设备数据、商城消费加上支付数据，全部在小米的生态内。如果你用的小米手机已经是主力机了，可以再给小米钱包增加权限——但需要知道这意味着什么。\n翼支付与和包支付 两家运营商旗下的支付工具放一起说，因为它们面临同一个核心问题：数据维度太多了。\n中国电信有 3 亿多实名用户，中国移动超过 14 亿（含物联网卡）。运营商手里本来就有身份证信息、实时位置轨迹、通话记录、上网日志。现在再加上支付交易流水和消费记录——这个数据集可以画出一个人生活的几乎全部轮廓。\n安全性上，国企的合规约束比民营平台严格，目前没有发生过重大泄露或盗刷事件。但翼支付账户直接绑定手机号，如果号码被人恶意挂失补卡，支付账户跟着就危险了。两家都有运营商特有的免费挂失保障，但前提是你及时发现。\n日常生活中用不上这两家就不用绑。如果你已经是电信或移动的长期用户，只绑一张小额借记卡并设好日限额。\n第四梯队：有安全硬伤 拼多多支付 拼多多支付背后的持牌机构是上海付费通。但核心问题不在付费通——在拼多多这个母公司对待用户数据的根本态度。\n2023 年 3 月，Google 的安全团队（Project Zero 级别的 Android 安全研究能力）发现拼多多 App 利用了 Android 系统未公开的漏洞——不是普通 bug，是 0-day 级别的安全漏洞——绕过用户授权读写其他 App 的私有数据、修改系统设置。Google 随即将拼多多从 Play 商店全线下架，持续了几个月。\n关于这个事件有几个关键点：\n利用 0-day 漏洞需要极高的安全研究能力。这意味着拼多多雇佣了具备攻击性安全研究能力的人，把能力用在了用户身上 工信部、网信办多次通报拼多多「违规收集个人信息」「超范围收集个人信息」「强制用户使用定向推送功能」 这些不是一次性疏忽，是持续多年的隐私合规问题 你愿意让一家把高水平安全能力用在你身上的公司保管你的银行卡信息吗？在拼多多买东西用微信支付或支付宝结算就够了——完全没必要把卡直接绑给拼多多支付。\n携程支付 2014 年 3 月，乌云漏洞平台上了一份报告，后来被包括《财经》在内的媒体广泛转载：携程的支付系统日志直接打印并存储了用户的银行卡号、CVV 安全码、有效期——以明文形式。\nPCI-DSS 安全标准有明确规定：CVV 在任何情况下都不允许被存储。加密也不行。不允许。这是支付安全行业一个绝对红线。\n能犯这个错误，说明在事发时携程支付的安全评审流程、代码审查制度和员工 PCI-DSS 培训全部没有起到该起的作用。单个工程师不可能独立导致这种后果——这是一个组织层面的合规和文化问题。\n需要承认的是，十年过去了，携程的安全体系和 2014 年已经完全不同。但这件事情的意义在于：它让我们看到了一个支付系统在不被监管真正穿透审查时，底线可以低到什么程度。\n任何时候在携程买机票酒店，用微信或支付宝支付，不要绑定携程支付。\n通联支付与富友支付 这两家的主营业务是面向商户的 B 端收单，个人用户很少直接接触。但如果你在某个线下商户被引导扫码付款时跳到了它们的页面，需要知道背景。\n通联支付：2016 年被央行通报「严重违规」，罚款 1110 万元。历史累计处罚超千万元，涉及银行卡收单违规、反洗钱违规。2023 年还牵涉到一起 9000 万元非法吸收公众存款关联案件。\n富友支付：多次因反洗钱违规和数据报送问题被央行处罚，消费者投诉累计上千条。一直在冲击港股上市但反复受挫，被市场质疑的点之一是在 IPO 前进行了超过净利润 3.65 亿元的「清仓式分红」。\n这两家如果作为消费者在终端碰到，不要绑定任何银行卡。\n苏宁支付与唯品支付 苏宁支付（易付宝）：苏宁集团近几年经营持续困难，由国资托管转型中。技术团队和安全投入大概率在缩减。没有重大安全事件记录，但也毫无技术亮点。\n唯品支付：2016 年用户数据泄露事件包含支付信息。作为垂直品牌特卖电商平台，安全团队规模与大厂不在同一量级。\n七、快速决策参考 如果你只想要结论，下面这张表是你需要的全部信息：\n7.1 绑卡建议总表 建议等级 推荐卡种 平台 核心理由 🟢 最稳妥 借记卡+信用卡均可 Apple Pay、云闪付、银联在线支付 硬件级Token化/EMVCo标准/直连发卡行,无商业变现动机 🟢 推荐 借记卡+信用卡均可 支付宝、财付通(微信支付) 全球一流风控能力,百亿级交易量打磨,2023年被重罚后合规整改 🟡 可用 信用卡优先 京东支付 风控框架完整,但持牌机构六年五罚、累计4200万、3000+用户投诉不知情扣款 🟠 谨慎 仅信用卡,设限额 抖音支付、美团支付、小米钱包(线上) 支付安全本身不差,核心风险在生态内数据高度集中和隐私边界模糊 🟠 谨慎 仅信用卡,设限额 翼支付、和包支付 运营商数据+支付数据维度过大,手机号挂失补卡风险需警惕 🔴 不推荐绑 — 拼多多支付、携程支付、苏宁支付、唯品支付 历史安全事件严重(0-day恶意代码被下架/明文CVV/数据泄露)或安全投入不足 🔴 不推荐绑 — 通联支付、富友支付 B端机构,多次严重违规,个人用户无必要绑定 7.2 按使用场景的选择 你的场景 最优选择 次优选择 不要用 iPhone 日常小额 Apple Pay 云闪付 — 安卓日常小额 云闪付 支付宝/微信 拼多多支付 大额交易(\u0026gt;5000元) 银联在线支付 云闪付 任何快捷支付 抖音购物 支付宝 微信支付 抖音支付(避免数据打通) 美团外卖/到店 支付宝 微信支付 美团支付(避免数据打通) 拼多多购物 微信支付 支付宝 拼多多支付 携程订票订酒店 微信支付 支付宝 携程支付 京东自营购物 微信支付 支付宝 — 八、如果你只看这一节 绑卡安全这件事上，有几个原则比任何技术分析都重要：\n1. 开一张 II 类账户专门做快捷支付。 招行 II 类账户每日进出限额 1 万元，把这张卡绑到各个支付平台上去。主力借记卡保持在所有外部渠道之外。最坏的情况下某个平台出问题，损失也卡在可控范围。\n2. 招行 App →「快捷支付管理」→ 每月看一遍。 把不认识或者已经不用的授权直接关掉。很多平台授权一次就永久有效，时间长了你自己都忘了绑过哪些。\n3. 大额付款统一用信用卡。 信用卡有 48 小时盗刷保障，争议交易可以拒付。借记卡是存款被直接划走，追讨流程慢得多——而且追回来之前这笔钱你用不了。\n4. 绑定新平台的同时立刻设限额。 招行 App 里可以按商户设单日单笔限额。就算平台出问题，损失的区间也是锁死的。\n5. 安全这件事，分散风险不如减少风险面。 不是铺开 17 个支付方式就能降低风险。少绑一个不靠谱的平台，比给 17 个平台都设好限额更安全。尤其是有历史污点的平台——第一次出问题是意外，多次出问题就是模式了。\n数据来源：中国人民银行总行及各地分支机构行政处罚信息公示、移动支付网公开统计、澎湃新闻、央广网、乌云漏洞平台（WooYun，已停止运营）、Google Android 安全团队公开披露。本文写于 2026 年 7 月，各平台安全状况动态变化中，建议每半年复查一次。如有事实错误或需补充的内容，欢迎指出。\n","permalink":"https://raysre.com/posts/17-payment-security-review/","summary":"\u003ch2 id=\"写在前面\"\u003e写在前面\u003c/h2\u003e\n\u003cp\u003e手上有两张招行卡，一张借记卡一张信用卡。最近整理快捷支付授权列表的时候发现，不知不觉绑了十几个平台——有些完全想不起来什么时候授权的。\u003c/p\u003e\n\u003cp\u003e仔细一想，每个平台都能从我的卡里扣钱，但我对它们的安全机制几乎一无所知。唯一的判断标准是「大厂，应该没事吧」。\u003c/p\u003e","title":"17 种快捷支付安全深度评测：你的招行卡绑了哪些？"},{"content":"环境概览 网络架构 Hermes 的部署拓扑：\n管理节点通过 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 路由不对都遇到过，后面踩坑记录里展开。\n可用模型 模型名称 Provider 场景 deepseek-auto ⭐ company-deepseek-auto 默认模型，智能路由，日常使用 deepseek-semantic-auto company-deepseek-semantic-auto 语义路由，需要精准理解意图时用 deepseek-v4-pro company-deepseek-v4 最强推理，复杂分析、长文档、架构设计 deepseek-v4-flash company-deepseek-v4-flash 快速响应，简单问答、翻译、代码片段 日常启动与退出 启动 hermes 在钉钉群里 @机器人 或在私聊里直接发消息即可交互。命令行环境下直接输入文本对话。\n对话中常用操作 操作 命令 查看帮助 /help 退出会话 /exit 或 /quit 开新话题 /new 撤销上一步 /undo 重试回答 /retry 给会话取名 /title 名称 切换模型 /model deepseek-v4-pro 查看用量 /usage 模型选择与切换 规则引擎速查 Hermes 支持通过 config.yaml 中的 rules 配置按关键词自动匹配模型。例如：\nrules: - keywords: [\u0026#34;架构\u0026#34;, \u0026#34;架构设计\u0026#34;, \u0026#34;系统设计\u0026#34;] model: deepseek-v4-pro provider: company-deepseek-v4 - keywords: [\u0026#34;翻译\u0026#34;, \u0026#34;translate\u0026#34;] model: deepseek-v4-flash provider: company-deepseek-v4-flash 每条规则包括：\nkeywords — 匹配用户输入的关键词列表 model — 指定使用的模型名 provider — 对应的后端 provider（可选） priority — 规则优先级（数值越大越优先，默认 0） 匹配后自动切换，不需要手动干预。\n临时切换模型 在对话里随时切，不影响上下文：\n/model deepseek-v4-pro 也可以传 provider+model：\n/model company-deepseek-v4/deepseek-v4-pro 多话题会话管理 这是近期新增的功能：一个 Hermes 实例里同时跑多个独立会话，互不干扰。\n使用场景 假设你同时处理三个话题：\n话题 会话名称 推荐模型 技术架构设计 技术架构 deepseek-v4-pro 项目日志分析 项目日志 deepseek-v4-pro 孩子英语教育 英语教育 deepseek-auto 每个会话有自己的对话历史、上下文和模型配置。启动新话题：\n/new 技术架构 然后在对话中设置模型：\n/model deepseek-v4-pro /title 技术架构 这样下次通过 hermes --continue 技术架构 就能直接回到这个对话。\n查看所有会话 hermes sessions list 输出会列出每个会话的 ID、名称、最后活跃时间。也可以用交互式界面浏览：\nhermes sessions browse 会话操作速查 操作 命令 当前会话改名 /title 新名称 开新会话 /new 或 /reset 撤销上一条 /undo 分支会话 /branch 列出所有会话 hermes sessions list 交互式选会话 hermes sessions browse 恢复命名会话 hermes --continue 名称 导出会话记录 hermes sessions export 名称.jsonl 删除旧会话 hermes sessions delete ID 会话内搜索 hermes sessions search 关键词 进阶：Profile 完全隔离 如果希望话题之间完全隔离——独立的记忆、独立的配置、甚至独立的 API Key——可以创建多个 Profile：\n# 创建新 profile hermes profile create 工作-架构设计 # 在该 profile 下配置不同的模型 hermes config set model deepseek-v4-pro --profile 工作-架构设计 # 使用指定 profile 启动 hermes --profile 工作-架构设计 每个 Profile 有自己独立的 skills、plugins、cron 和 memories。\n常用命令速查 基础命令 命令 作用 hermes 启动交互模式 hermes \u0026quot;你的问题\u0026quot; 单次问答模式 hermes --continue 名称 恢复命名会话 hermes --profile 名称 指定 Profile 启动 模型切换 命令 作用 /model deepseek-v4-pro 切换模型 /model list 查看可用模型 /model current 查看当前模型 会话管理 命令 作用 /new 名称 新建命名会话 /title 名称 当前会话改名 /branch 从当前位置分支新会话 /undo 撤销上一条消息 系统维护 命令 作用 hermes update 更新 Hermes hermes doctor 运行健康检查 /usage 查看 Token 用量 /status 查看当前运行状态 踩坑记录 以下是实际部署过程中踩过的坑。\n❌ Nginx 反代导致 401 认证错误 现象：客户端配置了正确的 API Key，但请求始终返回 401。\n原因：Nginx 默认不会透传 Authorization 请求头。反向代理到后端时，这个头被丢了。\n修复：在 Nginx 的 location 块里显式加上：\nproxy_set_header Authorization $http_authorization; 这个坑踩了两次——正常对话没问题，但上下文压缩（生成大请求）时偶发 401，因为压缩请求走了不同的连接路径，偶尔触发同一根因。\n❌ Realm 转发导致 404 现象：使用 Realm 做流量转发，所有请求返回 404。\n原因：Realm 不支持修改 Host 头，公司网关依赖 Host 做路由决策。\n解决：放弃 Realm，改为 Nginx proxy_pass 直接反代。\n❌ 请求超时 现象：长文本生成或复杂推理中途被断开，客户端收到超时错误。\n原因：Nginx 的 proxy_read_timeout 默认只有 60 秒，AI 后端生成长回复时经常超过这个时间。\n修复：\nproxy_read_timeout 600s; proxy_connect_timeout 60s; proxy_send_timeout 60s; 确保同时使用 HTTP/1.1 长连接：\nproxy_http_version 1.1; proxy_set_header Connection \u0026#34;\u0026#34;; 故障排查 快速诊断 遇到问题时按顺序执行：\n# 1. 检查 WireGuard 连通性 ping 10.10.0.4 # 2. 检查 Nginx 是否存活 curl -s -o /dev/null -w \u0026#34;%{http_code}\u0026#34; http://10.10.0.4:8000/v1/models # 3. 检查 Hermes 自身状态 hermes doctor # 4. 查看最近日志 tail -100 ~/.hermes/logs/hermes.log 常见问题 问题 可能原因 怎么解决 无法连接 WireGuard 断开 ping 10.10.0.4 检查连通性 模型报错 模型名拼写错误 检查 config.yaml 中的模型名和 provider 名称 Token 耗尽 当月额度用完 联系管理员续期 响应超时 Nginx 超时太短 已将 proxy_read_timeout 优化为 600s 会话丢失 未命名就退出了 用 hermes sessions list 查找 附录 A：Nginx 优化配置参考 server { listen 8000; server_name _; location /v1 { proxy_pass http://\u0026lt;upstream\u0026gt;; proxy_http_version 1.1; proxy_set_header Connection \u0026#34;\u0026#34;; 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 长连接避免频繁握手。\n文档基于 Hermes Agent 公开发布版本及公司内部部署实践整理，配置参数和功能以实际部署版本为准。文档编号：DOC-2026-0708-HERMES-V2。\n","permalink":"https://raysre.com/posts/hermes-dingtalk-guide/","summary":"\u003ch2 id=\"环境概览\"\u003e环境概览\u003c/h2\u003e\n\u003ch3 id=\"网络架构\"\u003e网络架构\u003c/h3\u003e\n\u003cp\u003eHermes 的部署拓扑：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e管理节点\u003c/strong\u003e通过 WireGuard 接入公司内网，网段 \u003ccode\u003e10.10.0.0/24\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e\u003ccode\u003e10.10.0.4\u003c/code\u003e\u003c/strong\u003e 上运行 Nginx 反向代理，监听 \u003ccode\u003e0.0.0.0:8000\u003c/code\u003e，后端接 DeepSeek 网关\u003c/li\u003e\n\u003cli\u003e所有 API 请求统一走 \u003ccode\u003ehttp://10.10.0.4:8000/v1\u003c/code\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cblockquote\u003e\n\u003cp\u003e这条链路踩过坑。Nginx 不传 Authorization 头、超时不够、Host 路由不对都遇到过，后面踩坑记录里展开。\u003c/p\u003e","title":"Hermes 使用教程：从启动到故障排查的完整记录"},{"content":"写在前面 我有一个域名 raysre.com，放在那儿很久没什么用。最近打算把它变成个人博客——要求很简单：纯静态、不维护服务器、更新成本接近零。\n选了 Hugo（Go 写的静态站点生成器，hugo build 整个站点不到 200ms）+ PaperMod 主题（极简，不需要 Webpack/PostCSS 那一套）。托管在腾讯云 COS（对象存储），套一层 EdgeOne（腾讯云的边缘加速产品，对标 Cloudflare），通过 GitHub Actions 推送代码自动上线。\n这条路踩了几个坑。COS 的「公有读私有写」和 EdgeOne 的「私有访问授权」组合在一起会产生一个让人摸不着头脑的 AccessDenied。调试过程花了不少时间翻文档，顺带把 EdgeOne 和 COS 里那些没用到但经常被问到的功能也一并理了。\n这篇文章是从零到上线的完整记录，加上排查过程、配置解读、概念速查。没用到腾讯云功能的内容放进进阶参考，最后附 FAQ。\n整体架构 各组件分工：\n层级 用什么 负责 写作 Markdown 文章内容，存在 GitHub 仓库里 构建 Hugo 0.164.0 + PaperMod Markdown → HTML/CSS/JS，hugo --minify 压缩输出 构建环境 GitHub Actions 每次 git push main 自动构建+上传 存储 腾讯云 COS（上海，标准存储） 存 HTML/CSS/JS/图片等静态文件 加速+安全 腾讯云 EdgeOne 边缘缓存、HTTPS 终结、DDoS 基础防护、www 跳转 DNS 腾讯云 DNSPod raysre.com → EdgeOne CNAME 数据流是单向的：\n开发者 git push → GitHub Actions → hugo build → public/ → Python SDK 上传 COS → CDN 刷新 用户访问 raysre.com → EdgeOne 边缘节点（缓存命中）→ 返回缓存 → 用户 ｜缓存未命中 → 回源 COS → 返回 这个架构对个人博客来说有几个好处：不需要买云服务器，不需要维护 Nginx，COS 存储一个月几毛钱，EdgeOne 免费套餐 10GB/月流量够用。\n基础概念速查 配置过程中反复出现的几个概念，放在这里免得后面看不懂。\n概念 一句话 你博客里的角色 COS 存储桶 腾讯云的对象存储，类似 AWS S3 存 HTML 等静态文件 静态网站托管 COS 的一个功能，让桶像 Web 服务器那样响应 HTTP 请求 开了，但 EdgeOne 回源不用它 默认域名 COS 给每个桶分配的公网访问域名（xxx.cos.ap-shanghai.myqcloud.com） 2024 年 1 月后新建的桶不能用它预览网页（官方限制） 静态网站端点 另一个域名（xxx.cos-website.ap-shanghai.myqcloud.com），专门用于静态网站访问 开了，确认能用 HTTP 访问到页面 EdgeOne 加速域名 你自定义的域名接入 EdgeOne 后分配 CNAME（raysre.com.eo.dnse2.com） DNS CNAME 指到这儿 回源 CDN 节点缓存未命中时，向源站拉取文件 EdgeOne → COS 回源 HOST 头 CDN 回源请求中带的 Host 头，决定源站识别哪个站点 配置错误导致 AccessDenied 的关键字段 CNAME DNS 里把域名指向另一个域名的记录 raysre.com CNAME → raysre.com.eo.dnse2.com 关键理解：COS 有两套域名体系。\n域名类型 格式 用在哪 默认域名（API 端点） bucket.cos.region.myqcloud.com SDK 上传文件、API 操作 静态网站端点 bucket.cos-website.region.myqcloud.com 浏览器直接访问静态网站 EdgeOne 如果用「对象存储源站」模式回源到默认域名，走的不是静态网站逻辑。你用浏览器访问 https://raysre.com/index.html，EdgeOne 回源时相当于向 COS 的 API 端点发起 GET 请求，这时候如果桶是私有读，会直接返回 AccessDenied——这就是后面排查过程中掉进去的坑。\nStep 1：Hugo 环境搭建 Hugo 用的是 v0.164.0 extended 版 + PaperMod 主题。注意 PaperMod 是 submodule，克隆仓库时带 --recurse-submodules：\n# 新建站点 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 行，去掉了默认配置的冗余项）：\nbaseURL = \u0026#39;https://raysre.com/\u0026#39; # 生产环境域名，决定所有绝对链接 locale = \u0026#39;zh-cn\u0026#39; title = \u0026#39;DevOps工作笔记\u0026#39; theme = \u0026#39;PaperMod\u0026#39; [params] description = \u0026#39;工作与生活随记\u0026#39; author = \u0026#39;阿端\u0026#39; ShowToc = true # 显示文章目录 ShowBreadCrumbs = true # 面包屑导航 ShowReadingTime = true ShowWordCount = true [markup.tableOfContents] startLevel = 2 # 目录只显示 h2/h3 endLevel = 3 构建命令：\nhugo --minify # 构建并压缩，输出到 public/ hugo server -D # 本地预览，--watch 默认开启 备案展示——PaperMod 默认的 footer.html 没有备案号。在 layouts/partials/footer.html 里加了：\n\u0026lt;div style=\u0026#34;text-align:center;font-size:12px;color:#888;margin-top:10px\u0026#34;\u0026gt; \u0026lt;a href=\u0026#34;https://beian.miit.gov.cn/\u0026#34; target=\u0026#34;_blank\u0026#34; rel=\u0026#34;noopener\u0026#34;\u0026gt; 沪ICP备2026021650号-1 \u0026lt;/a\u0026gt; \u0026lt;span style=\u0026#34;margin:0 8px\u0026#34;\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;a href=\u0026#34;http://www.beian.gov.cn/portal/registerSystemInfo?recordcode=31011502406637\u0026#34; target=\u0026#34;_blank\u0026#34; rel=\u0026#34;noopener\u0026#34;\u0026gt; \u0026lt;img src=\u0026#34;/images/beian.png\u0026#34; style=\u0026#34;display:inline;height:14px;vertical-align:middle\u0026#34; alt=\u0026#34;\u0026#34;\u0026gt; 沪公网安备 31011502406637 号 \u0026lt;/a\u0026gt; \u0026lt;/div\u0026gt; 公安备案图标 beian.png 放 static/images/ 下，构建时会原样复制到 public/images/。\nStep 2：COS 存储桶配置 腾讯云 COS 控制台操作清单：\n配置项 设置 原因 地域 上海（ap-shanghai） 和 GitHub Actions runner 延迟低，和 EdgeOne 节点同地域回源走内网 访问权限 公有读私有写 最早设置；后面排查 AccessDenied 时临时改过，最终改回私有读写+EdgeOne 回源鉴权 静态网站托管 开启，默认首页 index.html Hugo 生成的就是 index.html 自定义源站域名 不配置 COS 的自定义域名和 EdgeOne 是两条路，用了 EdgeOne 就没必要在 COS 里再配 防盗链 Referer 白名单：空 Referer + raysre.com 防止其他网站直接盗链 COS 默认域名 关于访问权限的最终方案：\n桶设为私有读写，在 EdgeOne 里开启私有访问授权。EdgeOne 回源 COS 时会带上内部鉴权签名，COS 认这个签名放行。用户在浏览器里直接打 COS 默认域名会返回 403。\n这样做的好处：COS 源站不暴露公网入口，只有 EdgeOne 能回源取文件。\nStep 3：GitHub Actions 自动部署 deploy.yml 总长 145 行，分 5 个步骤：\n步骤 做什么 耗时参考 Checkout 拉仓库 + PaperMod submodule 3-5s Setup Hugo 下载 Hugo 0.164.0 extended 二进制 2-3s Build hugo --minify \u0026lt;1s Deploy to COS Python SDK 遍历 public/ 上传，带 Content-Type 10-20s Purge CDN Cache 调 CDN API 刷新首页缓存 1-2s Setup Hugo 步骤：从 GitHub Releases 直接下载，不用 peaceiris/actions-hugo 这种第三方 Action——少依赖就是少隐患。指定版本 0.164.0 防止某天自动升版导致构建行为变化。\nDeploy 步骤逐段拆解：\n# 第一段：MIME 类型映射表 MIME = { \u0026#39;.html\u0026#39;: \u0026#39;text/html; charset=utf-8\u0026#39;, \u0026#39;.css\u0026#39;: \u0026#39;text/css; charset=utf-8\u0026#39;, \u0026#39;.js\u0026#39;: \u0026#39;application/javascript; charset=utf-8\u0026#39;, \u0026#39;.svg\u0026#39;: \u0026#39;image/svg+xml\u0026#39;, # ... 16 种常见格式 } 不设 Content-Type 的话，COS 默认给所有文件 application/octet-stream。浏览器拿到不认识就当成下载，CSS/JS 不生效，页面直接崩。所以每个文件上传时必须带正确的 MIME。\n# 第二段：遍历上传 local_dir = \u0026#39;public\u0026#39; 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(\u0026#39;/\u0026#39;) ext = os.path.splitext(f)[1].lower() content_type = MIME.get(ext, \u0026#39;application/octet-stream\u0026#39;) with open(local_path, \u0026#39;rb\u0026#39;) as fp: client.put_object( Bucket=\u0026#39;raysre-1377355589\u0026#39;, 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 路径对应。\n为什么用 Python SDK 而不是 coscmd：\n方案 问题 coscmd CLI GitHub Actions 默认不带，需要 apt-get 装；配置文件要文本替换密钥，麻烦 cos-python-sdk-v5 pip install 一行搞定，密钥走环境变量，代码即配置 Purge CDN 步骤：调腾讯云 CDN API PurgeUrlsCache，签 V3 签名算法（TC3-HMAC-SHA256），刷新首页和 www 两个 URL。Hugo 新构建的文件名含 hash（如 main.abc123.css），自然绕过旧缓存——所以不需要全站刷新，只刷首页让用户拿到新文件引用就够了。\nSecrets 配置：TENCENT_SECRET_ID 和 TENCENT_SECRET_KEY 必须放 GitHub Repository secrets（不是 Environment secrets）——走 Environment 的话 deploy.yml 里 ${{ secrets.XXX }} 拿不到值。这个区分是排查早期构建失败时发现的。\nStep 4：EdgeOne 配置 \u0026amp; AccessDenied 排查 第一版配置（翻车） 配置项 值 加速域名 raysre.com 源站类型 对象存储源站 源站地址 默认域名（raysre-1377355589.cos.ap-shanghai.myqcloud.com） 私有访问授权 开启 回源 HOST 头 使用源站域名 git push 后 Actions Run #9 成功上传 30+ 个文件但浏览器访问 https://raysre.com/ 返回 AccessDenied XML：\n\u0026lt;Error\u0026gt; \u0026lt;Code\u0026gt;AccessDenied\u0026lt;/Code\u0026gt; \u0026lt;Message\u0026gt;Access Denied.\u0026lt;/Message\u0026gt; \u0026lt;Resource\u0026gt;/\u0026lt;/Resource\u0026gt; \u0026lt;RequestId\u0026gt;...\u0026lt;/RequestId\u0026gt; \u0026lt;/Error\u0026gt; 而直接访问 COS 静态网站端点 http://raysre-1377355589.cos-website.ap-shanghai.myqcloud.com/ 能正常显示。\n定位过程 做了几个测试：\n测试 结果 结论 curl -sv https://raysre.com/ 403 AccessDenied EdgeOne 代理层面就返回了 403 curl -sI http://cos-website域名/ 200 + HTML COS 静态网站本身正常 curl -s https://默认域名/index.html 200 + 完整 HTML 默认域名公网可访问（当时桶是公有读） 根因：EdgeOne「私有访问授权」开启时，会构造一个鉴权签名放在回源请求中。但这个签名是针对 COS API 端点的——不是针对静态网站端点的。而用「对象存储源站」模式回源的地址恰恰好是 API 端点地址（默认域名）。COS 收到带签名的请求后发现签名和请求不匹配：API 端点期望的签名格式和静态网站的授权逻辑不一样。\n换句话说：公有读桶 + 私有访问授权 = 冲突。公有读桶不需要鉴权就能访问，开了私有访问授权反而让 EdgeOne 构造了一个多此一举的签名，COS 校验失败直接拒。\n修复版本（正确配置） 配置项 旧值 新值 COS 桶权限 公有读 私有读写 EdgeOne 私有访问授权 开启 保持开启 EdgeOne 回源 HOST 头 源站域名 使用源站域名（不变） 修复逻辑：先让 EdgeOne 去 COS 完成授权绑定，等 COS 桶策略里出现一条允许 EdgeOne 服务访问的策略后，再把桶改为私有读写。这样 EdgeOne 回源带签名，COS 认这个签名放行。外面直接打 COS 默认域名因为没有签名，直接 403。\n附加规则 URL 重写（解决 / 不自动返回 index.html）：\n匹配条件 操作 目标 URL Path 等于 / URL 重写 /index.html 这一步是关键。EdgeOne 回源到 COS API 端点时 GET / 不等于 GET /index.html，不像 Nginx 那样有 try_files。不加这个规则首页永远 403。\nwww 301 重定向：\n项 配置 DNS 添加 CNAME 记录 www.raysre.com → raysre.com.eo.dnse2.com EdgeOne 域名 添加加速域名 www.raysre.com，源站和 raysre.com 相同 EdgeOne 规则引擎 匹配 HOST = www.raysre.com → 访问 URL 重定向 301 → https://raysre.com${uri} ${uri} 是 EdgeOne 内置变量，保留原始路径。比如 www.raysre.com/posts/xxx → raysre.com/posts/xxx，不会全部丟到首页。\nStep 5：DNS 切换 DNSPod 控制台里把 raysre.com 和 www.raysre.com 的 A 记录删掉（如果之前指向了服务器 IP），改成 CNAME：\n记录类型 主机记录 记录值 TTL CNAME @ raysre.com.eo.dnse2.com 600 CNAME www raysre.com.eo.dnse2.com 600 TTL 设 600 秒（10 分钟），初次调试时改配置能更快生效。稳定运行后可以调回 3600。\n成本估算 以我这个站的实际用量（文章 3 篇、访问量可以忽略）：\n计费项 月费（估算） COS 存储（标准存储，\u0026lt;1GB） ¥0.10 COS 请求费（几千次/月） ¥0.01 CDN 流量（\u0026lt;10GB/月） 免费套餐覆盖 CDN 请求费 免费套餐覆盖 DNS 解析 免费 总计 ≈ ¥0.11/月 对个人博客来说几乎免费。唯一需要留意的：CDN 免费套餐每月 10GB 国内流量，如果哪天文章被大量访问超额，按量计费部分 ¥0.21/GB——设置好「用量封顶」防止意外。\n进阶参考：没用到的腾讯云功能 下面这些是 EdgeOne 和 COS 提供的功能，个人博客场景用不到，但如果你要从静态博客拓展到更复杂的场景，可以参考。\nEdgeOne 四层代理（L4 Proxy） 用 TCP/UDP 协议加速，适用场景是游戏加速、IoT 设备通信、实时音视频——不走 HTTP。静态博客只用七层（HTTP/HTTPS）。\nEdgeOne 边缘函数（Edge Functions） 在 EdgeOne 边缘节点上跑 JavaScript 代码，类似 Cloudflare Workers。可以做的事：自定义鉴权、A/B 分流、响应头注入、内部重定向。比规则引擎灵活，但需要写代码。如果你要实现「特定 IP 段跳转到维护页」这种逻辑，用边缘函数比规则引擎方便。\n回源限频 限制 EdgeOne 向源站发起的请求频率。作用是高并发时保护源站不被击穿。文档里典型的参数是「同一 URL 每秒最多回源 1 次」。个人博客流量小，可以不开。\nEdgeOne 用量封顶 设置流量 / 带宽 / QPS 上限，达到后自动限速或返回提示页。建议设一下——免费套餐有额度限制，防止某个月被刷流量产生天价账单。\nCOS 回源设置 当请求的对象在 COS 桶里找不到时，自动去一个预设地址拉取内容。用于数据热迁移场景（如从旧服务器逐步搬到 COS）。不用于静态博客——所有文件由 GitHub Actions 上传，不会出现 404。\nCOS 生命周期管理 自动把对象从标准存储切换到低频 / 归档 / 深度归档，或到期后自动删除。如果你的桶存了大量日志需要定期清理，这是一个有用的功能。\nCOS 智能分层存储 自动在「高频」和「低频」两个访问层之间迁移对象，不需要手动配生命周期。访问模式不可预测时比生命周期省心。\n数据万象 CI（图片/音视频处理） 和 COS 绑定的数据处理服务，提供实时图片裁剪、水印、格式转换（比如 ?imageMogr2/thumbnail/200x），以及视频转码、截帧等能力。如果你以后需要在文章里自动生成缩略图、加水印，数据万象是实现方案之一。\nCOS 标签管理 给对象打标签（如 env=prod, category=blog），方便分类、成本核算和批量操作。\nFAQ Q：为什么 hugo.toml 不用 yaml 格式？ hugo new site --format yaml 生成的就是 TOML（这个参数有点误导，实际上 Hugo 默认生成 TOML）。TOML 比 YAML 更不容易出现缩进错误，而且 Hugo 文档里的示例代码基本是 TOML，复制粘贴改起来方便。\nQ：deploy.yml 在 GitHub Actions 里报 ModuleNotFoundError: No module named 'qcloud_cos' 怎么处理？ - run: pip install cos-python-sdk-v5 加在 Deploy 步骤最前面。注意每次 step 的 shell 环境可能不同，pip install 放在同一个 run: 块里，不要跨 step。\nQ：如何验证 COS 静态网站端点正常工作？ curl -sI http://raysre-1377355589.cos-website.ap-shanghai.myqcloud.com/index.html 预期返回 200 OK + Content-Type: text/html。如果不是 200，去 COS 控制台检查静态网站托管是否开启、默认首页是否设了 index.html。\nQ：HTTPS 证书怎么搞？ EdgeOne 免费提供 DV SSL 证书，接入域名后自动申请，不需要额外操作。如果 www 也需要扫码 HTTPS，申请时勾选多域名即可。\nQ：PaperMod 怎么加备案号？ 在 layouts/partials/footer.html 里覆盖默认模板。PaperMod 的默认 footer 位于 themes/PaperMod/layouts/partials/footer.html，把内容复制过来，底部追加备案信息。Hugo 发现项目 layouts/ 下同名文件会优先用你的，不会动主题原文件。\nQ：文章更新后旧页面能看到吗？ 能看到。Hugo 构建时 CSS/JS 文件名含内容 hash，新版本文件名不同。旧文件还在 COS 上，EdgeOne 缓存里旧的 HTML 引用旧 JS——所以 deploy 后加了一步 CDN 刷新。\nQ：COS 默认域名能被直接访问吗？ 取决于桶权限。如果你设了私有读写+EdgeOne 私有访问授权，直接打 COS 默认域名会 403。顺手加 Referer 白名单可以多做一层防护。\nQ：为啥不用 Cloudflare Pages / Vercel？ Cloudflare Pages 免费 500 次/月构建，Vercel 免费 6000 分钟/月。两家托管在国内的访问稳定性时好时坏——不是产品不行，是物理距离在那儿。腾讯云 COS + EdgeOne 面向国内用户，延迟 \u0026lt;50ms，在线率有 SLA。如果你的受众主要在海外，那 Cloudflare Pages 反倒更合适。\nQ：文章多了以后构建和上传会变慢吗？ Hugo 官方的基准测试数据：5000 篇文章的站点，hugo build 在 1 秒内完成。瓶颈在上传：os.walk() 顺序串行，文件数到几千时可以考虑用 ThreadPoolExecutor 并行化上传。目前几十个文件串行够用。\n写在最后 整个过程踩的最大坑是 EdgeOne 的「私有访问授权」和「公有读桶」的组合——文档里散落在不同页面，没有明确的「桶公有读时不要开私有访问授权」的警告。这篇记录把配置关系理成表格，方便以后查。\n不用管服务器、不用打安全补丁、不用半夜被告警吵醒——COS 存文件，EdgeOne 扛流量，GitHub Actions 管发布。代价是没法跑动态内容（评论、登录、后台）。如果你需要这些，WordPress + 云服务器或者 Hugo + Serverless 评论更适合。\n如果你也在搭类似的个人博客，上面的 deploy.yml 可以直接拿走用，改个 bucket 名字就行。\n","permalink":"https://raysre.com/posts/hugo-cos-edgeone-deploy/","summary":"\u003ch2 id=\"写在前面\"\u003e写在前面\u003c/h2\u003e\n\u003cp\u003e我有一个域名 \u003ccode\u003eraysre.com\u003c/code\u003e，放在那儿很久没什么用。最近打算把它变成个人博客——要求很简单：纯静态、不维护服务器、更新成本接近零。\u003c/p\u003e\n\u003cp\u003e选了 \u003ca href=\"https://gohugo.io/\"\u003eHugo\u003c/a\u003e（Go 写的静态站点生成器，\u003ccode\u003ehugo build\u003c/code\u003e 整个站点不到 200ms）+ \u003ca href=\"https://github.com/adityatelange/hugo-PaperMod\"\u003ePaperMod\u003c/a\u003e 主题（极简，不需要 Webpack/PostCSS 那一套）。托管在腾讯云 COS（对象存储），套一层 EdgeOne（腾讯云的边缘加速产品，对标 Cloudflare），通过 GitHub Actions 推送代码自动上线。\u003c/p\u003e","title":"Hugo + 腾讯云 COS + EdgeOne 静态博客部署全记录 — 从零到上线填过的坑"},{"content":"背景 公司 Jira Data Center v10.3.3 集群的共享存储（NFS）跑在一块 7.8TB 的企业级 NVMe SSD 上，挂载路径 /data，实际数据量 7.0TB——全是 Jira 附件，不含数据库。\n要腾出这块 SSD 给别的业务，替换盘是一块 45.5TB 机械硬盘（/dev/sda，未初始化）。要求在下一个工作日 9:00 前完成迁移，尽可能减少停服时间。\n集群拓扑 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 ← 本次迁移对象 节点 角色 操作系统 说明 100.25 Nginx Ubuntu 24.04 nginx/1.31.2，反向代理 + 负载均衡 100.26 Jira Node 1 Ubuntu 24.04 应用服务器，su - jira 操作 100.27 Jira Node 2 Ubuntu 24.04 应用服务器，与 Node 1 组成集群 100.28 MySQL 主库 Ubuntu 24.04 MySQL 8.0.33，socket 连接 100.29 MySQL 从库 Ubuntu 24.04 MySQL 8.0.33，主从同步 100.30 NFS Server Ubuntu 24.04 Jira 共享存储，全部附件 所有 IP 为企业内网地址，仅运维团队可达。\n存储现状 迁移前的磁盘布局：\nvdb 7.8T NVMe SSD ── vdb1 ext4 /dev/vdb1 → /data (7.0T 已用) sda 45.5T HDD ── 未分区，未格式化 迁移后的目标布局：\nvdb 7.8T NVMe SSD ── 腾出 sda 45.5T HDD ── sda1 ext4 /dev/sda1 → /data (7.0T 已用) 机械盘容量是 NVMe 的近 6 倍，写入速度约 110~140 MB/s——这是全流程的硬瓶颈。\n方案选型 方案 做法 迁移总耗时 停服窗口 文件数影响 rsync 两遍 第一遍不停服、第二遍停服增量 两遍扫描，文件多则 20h+ 第二遍扫描时间 大 — 百万文件扫描几小时 rsync 一遍 停服后直接拷 一次性扫完写完 全程 大 — 同上 rsync 一遍（本方案） 停服后一次性拷，不做增量 10-14h 全程 小 — 10~14h 内文件数不构成瓶颈 三选一，选了停服 rsync 一遍。\n理由是 /data 目录下只有 Jira 附件、索引缓存等静态文件，不含写入中的数据库。停服后数据完全冻结，不存在 rsync 过程中文件被修改导致不一致的问题。7.0TB 数据，机械盘顺序写入 110+ MB/s，数学上 10~14 小时能跑完，停服窗口 24 小时绰绰有余。\n没有用 dd。dd 会复制整块 7.8TB 盘（含空闲空间），额外消耗约 1 小时且浪费目标盘空间。rsync 只传实际文件，且参数 -aHAX 能完整保留软链接、硬链接、ACL 和扩展属性。\n完整操作记录 所有命令在 NFS Server（10.177.100.30，root 用户）上执行。\n第一步：开 tmux 防断连 tmux new -s jira-migration SSH 连接意外断开时，tmux attach -t jira-migration 恢复会话。\n第二步：停服 # 停 Jira 所有节点 systemctl stop jira # 确认 /data 无进程占用 lsof +D /data 2\u0026gt;/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 全部给数据。\n第四步：执行迁移 mkdir -p /mnt/sda1 mount /dev/sda1 /mnt/sda1 # 核心传输命令 rsync -aHAX --info=progress2 --numeric-ids /data/ /mnt/sda1/ 参数逐项说明：\n选项 作用 为什么重要 -a archive 模式，等同 -rlptgoD 保留权限、时间戳、软链接、属主/属组、设备文件 -H 保留硬链接 Jira 附件目录可能有硬链接，不保留会导致空间膨胀 -A 保留 ACL NFS 客户端可能依赖 ACL 做访问控制 -X 保留扩展属性 安全上下文（SELinux/AppArmor）和 NFS xattr --info=progress2 全局进度条 7TB 传输不显示整体进度没法预估完成时间 --numeric-ids 数字 UID/GID 不解析用户名，避免目标机器不存在同名用户导致 ID 映射错误 /data/ 末尾斜杠 复制目录内容 不加斜杠会在目标盘创建 /mnt/sda1/data/ 额外层级 第五步：实际耗时记录 时间节点 状态 已传输 周六 23:48 启动 rsync 0 周日 11:03 运行 11h15m 4.4 TB 周日 16:20 运行 16h32m 6.3 TB 周日 18:10 完成 7.0 TB 实际耗时约 18 小时 22 分钟，平均速度 111 MB/s。比预估的 10-14 小时慢，原因是 Jira 附件目录中夹杂数十万个小文件（图标、缩略图、日志片段），随机寻道拉低了机械盘的实际写入吞吐。\n第六步：校验 # 数据量对比 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 \u0026amp;\u0026amp; systemctl restart nfs-server # 启动 Jira systemctl start jira Jira 启动后报错：\nJIRA couldn\u0026#39;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 客户端缓存未清理。\n解决：重启 Jira Node 1 和 Node 2，强制刷新 NFS 客户端缓存。\n# 在 10.177.100.26 和 10.177.100.27 上执行 reboot 重启后 Jira 正常启动，附件可访问，集群状态恢复。\n日常运维速查 以下命令在日常运维中高频出现，按场景归类备查。\nJira 启停 # 启动 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 关键配置文件位置 文件 路径 用途 Jira 集群配置 /data/jirasoftware/jira-home/cluster.properties 定义集群节点、共享目录路径 Jira 服务配置 /data/jirasoftware/jira/conf/server.xml 端口、上下文路径、连接池 Jira JVM 参数 /data/jirasoftware/jira/bin/setenv.sh 堆内存、GC 策略、JVM 选项 MySQL 配置 /data/mysql/conf/my.cnf 数据库引擎、缓冲池、二进制日志 NFS 导出 /etc/exports 允许哪些 IP 挂载 /data 自动挂载 /etc/fstab 系统启动时挂载磁盘 注意事项 停服前做最终状态确认。生产环境停服不是小事。除了 systemctl stop jira，还要 lsof +D /data 确认无一进程占用，NFS 客户端缓存可能导致静默写入。\nrsync 源路径末尾斜杠是坑。/data/ 和 /data 的区别是一层目录结构。用错了会让目标盘里塞一个多余的 /data/ 子目录，Jira 的 jira.home 配置指向的路径就找不到了。\n-m 0 不是默认参数。mkfs.ext4 不给 -m 参数时默认预留 5% 给 root。45TB 上的 5% 是 2.3TB——大到摸得着。NFS 数据盘生产用途明确，不需要反碎片化保护，全部空间给业务数据。\nNFS 切换后必须刷新两端缓存。服务端 exportfs -ra 刷新导出表，客户端重启或重新挂载清除内核 NFS 句柄缓存。只做一端的效果是 Jira 无法写入 shared_home 目录。\nJira Data Center 的 shared_home 路径不能变。cluster.properties 里硬编码了 /data/jirasoftware/jira-home/shared_home。迁移时目标盘挂载点必须完全一致（/data），否则需要停机修改集群配置并重启所有节点。\n回滚路径要保持到验证结束。迁移完成后 vdb 上的数据不要立刻清除。等 Jira 跑 2~3 个工作日，确认附件上传、全文搜索、集群同步都没问题，再考虑回收旧盘。遇到问题只需 umount /data \u0026amp;\u0026amp; mount /dev/vdb1 /data \u0026amp;\u0026amp; systemctl start jira 即可回退。\n小结 从一块 NVMe SSD 到一块机械盘，迁移 7TB Jira 附件数据，核心就一条 rsync -aHAX --info=progress2 --numeric-ids /data/ /mnt/sda1/。参数选对了，数据属性一件不少；停服窗口估准了，团队沟通在先，操作过程没有意外。\n机械盘写入带宽是硬天花板——111 MB/s 对 7TB 来说跑 18 小时无可避免。真正把时间从\u0026quot;超过 24 小时\u0026quot;压缩到 18 小时的是文件系统参数：-m 0 省了 2.3TB 无用写入，GPT 单分区省了 MBR 扩展分区链的开销。这些微调单独看都不起眼，叠在一起就是停服窗口能不能按时交付的差距。\n","permalink":"https://raysre.com/posts/jira-nfs-storage-migration/","summary":"\u003ch2 id=\"背景\"\u003e背景\u003c/h2\u003e\n\u003cp\u003e公司 Jira Data Center v10.3.3 集群的共享存储（NFS）跑在一块 7.8TB 的企业级 NVMe SSD 上，挂载路径 \u003ccode\u003e/data\u003c/code\u003e，实际数据量 7.0TB——全是 Jira 附件，不含数据库。\u003c/p\u003e\n\u003cp\u003e要腾出这块 SSD 给别的业务，替换盘是一块 45.5TB 机械硬盘（\u003ccode\u003e/dev/sda\u003c/code\u003e，未初始化）。要求在\u003cstrong\u003e下一个工作日 9:00 前\u003c/strong\u003e完成迁移，尽可能减少停服时间。\u003c/p\u003e","title":"Jira Data Center NFS 存储迁移实战：7TB 数据从 NVMe 到机械盘的无损切割"}]