性能调优：CPU 占用、GOMAXPROCS 与扫描间隔

先理解开销从哪来

官方 FAQ 把 CPU 消耗拆成四件事，全是设计内的开销：

1. SHA-256 哈希——新文件或首次扫描时逐块计算（首次同步尤其明显）；
2. 加密/解密——所有传输数据强制 TLS，接收端还要解压；
3. 索引维护——跟踪每个文件的当前与可用版本；
4. 周期扫描——watcher 关闭时每分钟一次、开启时每小时一次的完整核对，大文件夹会形成 CPU 峰值。

关键判断：同步完成、系统稳定后 CPU 应接近于零。长期高占用才需要动手调。

限制核心数：GOMAXPROCS

官方给出的方法是把环境变量 GOMAXPROCS 设为允许使用的最大核心数——四核机器设 2 即最多用一半算力。systemd 部署写在服务的环境变量里，Windows 任务计划写在动作参数前（或脚本里设置），GUI 集成包在其启动配置里设置。

程序自身也做了缓解：默认尝试降低进程优先级（setLowPriority 选项），让出前台响应性。

扫描机制的官方细节

理解扫描才知道调优方向：

• watcher（文件系统监视）默认开启，负责即时感知；
• 完整扫描默认每小时一次兜底（watcher 可能漏报）；
• 实际扫描时刻在设定间隔的 3/4 到 5/4 之间随机，避免所有文件夹同时扫；
• 扫描间隔可按文件夹调整：大而少变的文件夹拉长间隔省资源，官方文档明确支持这种用法。

低速设备的重点（NAS/树莓派/手机）

官方 FAQ 点名的第一瓶颈就是低功耗设备的 CPU。对策按性价比排序：

• 接受首轮同步慢——它是一次性的，后续增量同步只处理变化块；
• 给文件夹设合理的扫描间隔，少变的大目录不必频繁全扫；
• 同步口径收窄：用忽略规则挡掉无需同步的目录（见[.stignore 入门(../05-控制同步内容/01-stignore-basics.md)）；
• 网络层面确认没走中继（见[同步慢先看连接类型(../10-常见问题/01-faq-slow.md)）——这是比 CPU 更常见的瓶颈。

验证手段

首次启动日志里的 Hashing performance is ... MB/s 给出本机哈希吞吐基线；iperf 一类的工具可以分离「网络慢」与「算力慢」两个变量。