Seafile 云盘备份到本地磁盘:从 SeaDrive+rsync 踩坑到年度快照方案

Seafile 云盘备份到本地磁盘:从 SeaDrive+rsync 踩坑到年度快照方案

背景

一直以来我用 SeaDrive + rsync 的组合来备份 Seafile 云盘数据到本地磁盘。但用久了发现这个方案有一个根本性问题,值得写出来给同样在用 Seafile 的朋友避坑。

问题:SeaDrive 是虚拟盘,rsync 备份的可能只是"影子"

SeaDrive 的工作模式是 on-demand(按需下载):本地默认只保存"影子文件"(占位符),真正的文件内容要在被访问时才会从服务器拉取下来。

这意味着直接对 SeaDrive 挂载目录跑 rsync,会遇到两难:

  • 要么触发大量按需下载:rsync 遍历目录时把所有影子文件的实际内容都拉取一遍,速度慢、流量大,尤其是移动网络或跨境访问服务器时体验很差;
  • 要么根本没备份到完整内容:如果不触发下载,rsync 复制到的可能只是占位符,不是真实文件,备份形同虚设。

这也是我决定换方案的直接原因。

候选方案对比

方案说明适用场景
seaf-cli官方命令行同步客户端,本地是真实文件,非虚拟盘命令行环境、树莓派等 headless 设备
seafile-client(同步模式)官方桌面客户端,选"同步"而非"虚拟盘"有图形界面的常驻电脑
rclone + WebDAV利用 Seafile 的 WebDAV 接口做同步/备份想要多目标备份(同时备份到 S3、OneDrive 等)的场景
强制落盘后 rsync先遍历触发 SeaDrive 全量下载,再 rsync不推荐,效率低、逻辑 tricky

最终选择基于官方 seaf-cli,因为它本身就是同步工具,不需要再叠加 rsync 这一层,依赖轻,适合脚本化和定时任务。

我的场景:另一台电脑 + 移动硬盘,每年备份一次

具体需求是:

  • 不影响 Seafile 服务器端的数据;
  • 用一台额外的电脑,接上移动硬盘做本地留档;
  • 备份频率很低——一年一次

关键坑:官方客户端默认是双向同步

无论是 seafile-client 桌面版还是 seaf-cli,默认都是双向同步。这意味着如果备份电脑上误删了文件,或者移动硬盘故障导致文件丢失/损坏,这个"删除"或"损坏"状态会被同步推回服务器,造成反向污染——这是这套方案里最容易被忽视、也最危险的一点。

[Read More]

(待测试)跨境数字化完全指南:西班牙 ↔ 中国大陆

(待测试)跨境数字化完全指南:西班牙 ↔ 中国大陆

适用场景: 旅居西班牙的华人回国期间,需要访问西班牙政府系统、维持远程办公,以及无人值守地运维留守在家的树莓派节点。 版本: v5.5 | 覆盖:Cloudflare Tunnel 穿透(--protocol 参数修正为 http2 + 初始部署即加 --network host --log-opt max-size/max-file 日志限制 + 出口节点验证 + 三层封锁对策,Access 后台路径修正)· Zero Trust 访客隔离 · 树莓派自愈监控(Xray Reality 健康检查解除硬编码限制,修复 send_email() From 头编码 bug,alert_relay.py 收紧为 127.0.0.1 绑定 + hmac 恒定时间比较,报警架构改为国内节点优先直连、失败降级中继(推翻早期"SMTP 被封"的错误假设),新增 5.6 节:日志管理,Docker 容器日志限制 + logrotate(copytruncate)配置,避免长期无人值守运行后日志无限增长撑爆 SD 卡)· CF Workers 轻量转发(cfst 安装指南 + 按需手动优选)· Xray Reality IP 保证方案(住宅 IP + DDNS + Fallback 默认关闭 + 系统加固 + 客户端三层防线架构 + ufw CGNAT/Docker 网段自锁修复 + 伪装目标域名修正 + 第七节泛化双向部署 + sudoers 免密白名单分级设计,不加入 docker 组)· 第 2.7 节:西班牙访问国内网站保证国内 IP 出口,go-gost/gost v3 容器化 SOCKS5**+HTTP 双协议监听(补齐之前遗漏的 8080 端口,配合 2.7.1 节 iOS PAC 分流使用)**,新增 2.7.1 节:老 Mac/iOS 无法用 WARP 全局模式时的客户端方案

[Read More]

深入掌握 SSH 逃逸序列:从单层到多层会话的优雅断连技巧

如何在 SSH 会话(包括单层与多层嵌套)中使用逃逸序列优雅退出

在运维、开发环境中,我们经常使用 SSH(Secure Shell)来远程连接服务器。但有时在使用 SSH 的过程中可能会遇到各种问题,比如会话无响应,或者在多层嵌套的 SSH 登录中需要单独断开内层会话却不想影响外层连接。在本文中,我们将详细介绍如何在单层以及多层嵌套的 SSH 场景下,正确使用逃逸序列来优雅地断开连接。

SSH 逃逸序列简介

SSH 客户端内置了一组特殊的“本地逃逸序列”(Local Escape Sequences)。当你在 SSH 中按下 Enter 后紧跟 ~(波浪号)与某些特定字符时,这些序列将不会发送到远程服务器,而是会在本地被 SSH 客户端解释为特殊指令。

最常见也最有用的一个逃逸序列是:

Enter ~ .

其含义是:本地断开当前正在使用的 SSH 会话。

单层 SSH 会话中的断连方法

在只有一层 SSH 连接的情况下(例如:本机 -> 远程主机),当你在 SSH 会话中发现终端无响应、卡死,或想快速退出时,可以使用 Enter ~ . 来强制中断当前连接。

具体步骤:

  1. 确保你的终端当前处于 SSH 命令行中,先按下 Enter(回车)。
  2. 接着输入 ~.(波浪号加英文句号)。
  3. 此时 SSH 客户端会立即断开连接,而无需等待远程主机响应。

这在处理某些网络不稳定、服务器进程卡死或死循环的场景时非常有用。

举例:
假设你通过 ssh user@server 连接到一台服务器,但服务器出现卡死现象,你没有办法通过正常的 Ctrl+Cexit 等命令退出。这时你可以按 Enter(确保在新行上)、再输入 ~(波浪号) 和 .(英文句号) 来强制断开。

多层嵌套 SSH 会话问题

在实际工作中,常见的场景是:

[Read More]

双语阅读与pdf翻译工具踩坑记

从"找个带发音的翻译插件"到"折腾 PDF 翻译":一次完整的工具选型与踩坑记录

起因

最近在学西班牙语和练英语听力,想找一款 Chrome 翻译插件,既能双语对照阅读网页,又能带发音练听力。结果这一路调研下来,从浏览器插件查到开源 PDF 翻译工具,中间还顺带排查了一次真实的数据泄露事件、一次开源项目的"作者换号"疑云,最后在本地环境踩了一路 Python 依赖的坑。整理成文,希望对有类似需求的人有参考价值。


一、先找带发音的翻译插件

练听力的核心诉求是:划词/网页翻译时能朗读发音。调研了几款主流选项:

插件特点
沉浸式翻译(Immersive Translate)内置 AI 朗读引擎,多语言发音稳定,支持网页双语对照、PDF、字幕翻译
Trancy专为语言学习设计,YouTube/Netflix 双语字幕是强项,适合精听训练
ImTranslator老牌稳定,但朗读只能调用 Google/Microsoft 两个传统引擎,没有 AI 大模型加持,翻译质量天花板较低
有道词典划词翻译偏查词,适合精听时随手看音标发音
Google 翻译官方插件免费无广告,但朗读功能依赖系统语音包,很多语言(除英语外)经常没声音或效果差

小结论: Google 翻译插件的朗读问题不是个例——它调用的是系统自带语音引擎,而不是自研 TTS,所以受限于设备装了哪些语言包。想要稳定的多语言朗读,还是得选自带 TTS 引擎的插件(沉浸式翻译、Trancy 这类)。


二、双语对照阅读:免费版翻译质量为什么"感觉弱"

用了一段时间沉浸式翻译后发现,免费版对照阅读体验很好,但翻译质量偏弱。深挖之后发现原因:

  • 免费版额度用的是 Google/微软等传统机器翻译引擎
  • DeepL、GPT、Gemini、DeepSeek 这类高质量 AI 引擎虽然可以配置,但免费额度有限,超出后自动降级

于是横向比较了几款"能自己接 AI 引擎"的替代方案:

开源双语对照插件对比

插件排版模式翻译引擎是否内置 TTS
简约翻译(KISS Translator)段落上下对照(不是左右双栏)自己接入 API Key,质量取决于你选的模型❌ 无
FluentRead(流畅阅读)同上同上,GPL 开源,社区活跃❌ 无
Trancy同上内置微软翻译、GLM、DeepSeek,同样有免费额度限制有朗读功能
Read Frog(陪读蛙)同上通过 Vercel AI SDK 接入 20+ AI 服务商(OpenAI/DeepSeek/Claude/Gemini/Grok/Mistral/Ollama 等)内置 Edge TTS,150+ 语音、80+ 语言全免费

一个容易搞混的点: 无论沉浸式翻译还是这几款开源方案,“双语对照"指的都是原文和译文上下排列,不是页面左右分栏。真正的左右分栏排版更多见于双语电子书排版模板,浏览器翻译插件基本都是纵向对照的思路。

[Read More]

Python 环境与包管理指南

Python 环境与包管理指南

整理自对话讨论,涵盖 pip / pipx / uv / venv 的分工与实操命令,适用于日常开发(含 TaxEngine 税务计算脚本、pdf2zh PDF 翻译工具、yt-dlp 等命令行工具的环境管理)。


一、先搞清楚:你装的是"库"还是"工具"

在动手之前,先问自己一个问题:

这个东西是要在代码里 import 用的库,还是要在终端直接敲命令用的工具?

这个判断决定了你该用哪套方案:

类型举例推荐方案
代码里 import 的库pandasrequestsopenpyxlvenv + pip(或 uv venv
终端直接敲命令的工具yt-dlppdf2zhblackpipx(或 uv tool

二、四个工具的角色分工

工具管理对象是否隔离环境是否管理 Python 版本硬盘占用
pip当前激活环境里的库否(装进当前环境)
venv项目专属虚拟环境是(每项目一个)否(复用系统版本)较省
pipx命令行工具是(每工具一个独立环境)否(复用系统版本)较省
uv库 / 项目环境 / 命令行工具 / Python 版本(可自动下载指定版本)较大(每个 Python 版本都要占空间)

一句话总结分工逻辑:

[Read More]

youku规则

预设的分流规则包里通常会带一条 “block规则”(比如 block:category-ads-all 或类似的广告域名黑名单),把这些域名请求直接 reject 掉。

这为什么会影响优酷:

优酷本身的广告和内容分发是混在一起走的,很多所谓"广告域名"其实同时也承载了:

  • 视频播放的鉴权/token请求
  • 播放地址的重定向
  • 内容分发网络(CDN)的调度

如果规则把这类域名一并 block 了,优酷客户端/网页端会发现请求异常(连接被拒绝、超时、返回异常),这种行为模式跟"被防火墙/代理拦截"的表现很像,所以优酷的风控可能会把它误判成"存在异常网络環境(比如用代理)",进而限制播放——不一定是它真的检测到代理本身,而是检测到了请求被中途阻断的异常模式

怎么兼顾"优酷能看"和"国内广告能屏":

思路是不要用一刀切的"域名在不在 geosite:cn 里"来判断,而是单独把优酷相关的域名列出来直连,其他的国内网站广告该拦还拦。

从日志能看出两类域名,可以按这个思路分类打规则:

明显是广告/统计,可以放心 block:

domain:yk-ssp.ad.youku.com    ← 优酷广告SSP服务器(ad. 前缀已经说明是广告)
domain:ykad-data.youku.com    ← 广告数据回传(ad 关键字明显)
domain:qzs.gdtimg.com         ← 腾讯广点通(GDT)广告CDN
domain:mmstat.com             ← 阿里妈妈统计/广告追踪,覆盖 yt.mmstat.com / gm.mmstat.com / log.mmstat.com / yt1.mmstat.com 这一串
domain:image.9xsecndns.cn     ← 域名很可疑(伪装成普通CDN的广告/反广告屏蔽域名),可以先加入观察,如果加入block后视频还正常,就保留block

播放必需,千万别 block(要保证走 direct 且在 block 规则之前匹配到):

domain:v.youku.com
domain:acs.youku.com          ← 核心API/鉴权
domain:un-acs.youku.com
domain:acg.youku.com
domain:static.youku.com
domain:ykimg.com              ← m.ykimg.com 等图片域名
domain:www.youku.com
domain:pl-ali.youku.com       ← 播放列表
domain:cibntv.net             ← valipl.cp31.ott.cibntv.net,真正的视频流CDN,千万不能block
domain:cnpassport.youku.com   ← 登录鉴权
domain:pis-pcdn.youku.com
domain:drm-license.youku.com  ← DRM授权,block了直接放不了片
domain:player-gw-s.aliyuncs.com
domain:kacs-access.aliyuncs.com
domain:alicdn.com             ← g.alicdn.com / hudong.alicdn.com / at.alicdn.com 等一堆静态资源
domain:alipayobjects.com
domain:aliyuncs.com(如果没被上面覆盖到的话)

精简后的规则(按顺序):

[Read More]

Apple ID 国区迁移美区完全指南 (V2)

Apple ID 国区 → 美区迁移指南

本文目标:把一台 iPhone 从中国区 Apple ID 完整、无损地迁移到一个全新的美区 Apple ID,同时尽量保留照片、密码、健康数据、App 数据等内容。

适用对象

✅ 已经/准备新建一个独立的美区 Apple ID ✅ 希望以后所有 iCloud 同步都转移到美区 ✅ 接受"新建账号"而不是"原地改区"的方案

❌ 只是想改 App Store 商店国家(不换账号)——直接走"方式一:直接改区"即可,不需要做下面的整套备份/退出/恢复流程 ❌ 想长期让两个 iCloud 账号在同一设备共存 ❌ 企业 MDM 管控设备


迁移原理(先搞懂再动手)

旧 Apple ID(国区)
       │
       ▼
 iCloud 同步数据(云端,保留在原账号下)
       │
       ▼
 Finder/iTunes 本地加密备份(存在电脑硬盘里,不依赖任何云)
       │
       ▼
 手机抹机,进入纯净状态
       │
       ▼
 登录全新美区 Apple ID
       │
       ▼
 用 Finder 恢复刚才那份本地备份
       │
       ▼
 App、密码、健康数据等大部分本地内容会恢复到手机(极少数和硬件安全区绑定的内容,比如 Wallet 卡片、HomeKit 配对状态,可能仍需手动重新设置)
       │
       ▼
 重新打开 iCloud 同步开关 → 数据开始上传到美区 iCloud

关键点:本地加密备份是整个迁移的核心,因为它绕开了"两个 iCloud 账号之间数据不会自动互通"这个限制,靠物理备份/恢复把数据搬过去。

[Read More]

ThinkPad X1 Carbon 4th Gen (X1C4) Hackintosh:Catalina → Monterey 升级手册

ThinkPad X1 Carbon 4th Gen (X1C4) Hackintosh:Catalina → Monterey 升级手册

适用机型:Lenovo ThinkPad X1 Carbon 4 (Model 20FB) CPU:Intel Core i7-6600U (Skylake) | GPU:Intel HD Graphics 520(纯集显) 当前 OpenCore:0.8.4 | 目标系统:macOS 12.x Monterey 文档版本:2026-06-26,经 Claude / Gemini / ChatGPT 三方交叉核实


0. 升级前结论速览

风险项等级备注
CPU (Skylake)极低Apple 官方支持到 Monterey
HD Graphics 520极低WhateverGreen 完整支持,加速正常
声卡极低AppleALC 成熟方案
SMBIOS (MacBookPro13,x)极低Monterey 原生支持,Ventura 起被弃用
OpenCore 版本 (0.8.4)极低已满足 Monterey 所需的 0.7.4+ 门槛,无需强制升级
睡眠/唤醒Skylake 平台偶有唤醒黑屏报告,需关注
电池状态显示ECEnabler 方案延续即可
USB 端口映射macOS 11.3+ 起 XhciPortLimit 失效,必须提前完成映射
WiFi (AirportItlwm)中高三方意见一致认定的最高风险项,版本必须匹配 Monterey
旧 EFI/Kext 版本老化真正的风险不是 Monterey 本身,而是 2022 年左右的 kext 是否需要整体刷新

版本终点提示:MacBookPro13,x 系列 SMBIOS 在 macOS Ventura (13) 被 Apple 弃用,Sonoma 及以上需要 OpenCore Legacy Patcher (OCLP) 才能继续升级。Monterey 12.7.x 是这台 X1C4 性价比最高、最省心的稳定终点版本,如无强烈需求不建议追新到 Ventura 之后。

[Read More]

vi文本跳转操作快捷

vim/vi文本跳转操作快捷:

  1. 跳到文本的最后一行:按“G”,即“shift+g”。
  2. 跳到文本的第一行的第一个字符:按两次“g”。
  3. 跳到当前行的最后一个字符 :在当前行按“$”键,即“shift+4”。
  4. 跳到当前行的第一个字符:在当前行按“0”。

Agent 工作流搭建总结

AI Coding Agent 工作流搭建总结

受控执行型系统 · Intel Mac 2018 · 双系统路线


一、硬件底座与系统分支

设备: MacBook Pro 15-inch (2018, Intel i7, 16GB RAM)

根据系统版本,路线完全不同——先确认你的 macOS 版本:

系统版本工具选择原因
macOS 12 MontereyVS Code 1.123 + ClineVS Code 原生兼容,Cline 插件完整支持
macOS 10.15 CatalinaOpenCode CLIVS Code 从 v1.86 起断供 Catalina,Cline 无法正常运行

以下第二至十章为 macOS 12 Monterey + Cline 路线。 Catalina 用户请直接跳至 附录:macOS 10.15 Catalina — OpenCode CLI 路线

三条共同硬限制(两个路线均适用):

  • 本地推理不可行:Ollama / Qwen 等本地模型在 16GB 机器上会触发风扇满载
  • 固定订阅不划算:$20/月网页端 Pro 存在阵发性闲置,且有 Token 限流
  • 唯一出路:轻量工具 + 云端 API 按量计费,推理在云端,本地负载极低

二、工具范式对比

维度Cline (VS Code 插件)OpenCode (Terminal)Claude Code (CLI)
定位IDE 内结对程序员任务编排系统全自动驾驶系统
核心机制Human-in-the-loopMulti-agent 编排Context Compaction
交互界面Sidebar 可视化 DiffTerminal / Session 隔离纯文本 CLI
适合场景非连续开发、多 Debug自动化流水线大型旧库长周期重构
老 Mac 负载极低极低

现阶段选择:Cline,原因是 Human-in-the-loop 可视化 Diff 适合建立初期纪律,后续可无缝迁移至 OpenCode / Claude Code。

[Read More]